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Preamble 

In  August  of  1998  the  Collaborative  Agent  Design  Research  Center  (CADRC)  of  the 
California  Polytechnic  State  University  in  San  Luis  Obispo  (Cal  Poly),  approached  Dr. 
Phillip  Abraham  of  the  Office  of  Naval  Research  (ONR)  with  the  proposal  for  an  annual 
workshop  focusing  on  emerging  concepts  in  decision-support  systems  for  military 
applications.  The  proposal  was  considered  timely  by  the  ONR  Logistics  Program  Office  for 
at  least  two  reasons.  First,  rapid  advances  in  information  systems  technology  over  the  past 
decade  had  produced  distributed  collaborative  computer-assistance  capabilities  with 
profound  potential  for  providing  meaningful  support  to  military  decision  makers.  Indeed, 
some  systems  based  on  these  new  capabilities  such  as  the  Integrated  Marine  Multi-Agent 
Command  and  Control  System  (IMMACCS)  and  the  Integrated  Computerized  Deployment 
System  (ICODES)  had  already  reached  the  field-testing  and  final  product  stages, 
respectively. 

Second,  over  the  past  two  decades  the  US  Navy  and  Marine  Corps  had  been  increasingly 
challenged  by  missions  demanding  the  rapid  deployment  of  forces  into  hostile  or  devastated 
territories  with  minimum  or  non-existent  indigenous  support  capabilities.  Under  these 
conditions  Marine  Corps  forces  had  to  rely  mostly,  if  not  entirely,  on  sea-based  support  and 
sustainment  operations.  Particularly  today,  operational  strategies  such  as  Operational 
Maneuver  From  The  Sea  (OMFTS)  and  Sea  To  Objective  Maneuver  (STOM)  are  very 
much  in  need  of  intelligent,  near  real-time  and  adaptive  decision-support  tools  to  assist 
military  commanders  and  their  staff  under  conditions  of  rapid  change  and  overwhelming 
data  loads. 

In  the  light  of  these  developments  the  Logistics  Program  Office  of  ONR  considered  it 
timely  to  provide  an  annual  forum  for  the  interchange  of  ideas,  needs  and  concepts  that 
would  address  the  decision-support  requirements  and  opportunities  in  combined  Navy  and 
Marine  Corps  sea-based  warfare  and  humanitarian  relief  operations.  The  first  ONR 
Workshop  was  held  April  20-22,  1999  at  the  Embassy  Suites  Hotel  in  San  Luis  Obispo, 
California.  It  focused  on  advances  in  technology  with  particular  emphasis  on  an  emerging 
family  of  powerful  computer-based  tools,  and  concluded  that  the  most  able  members  of  this 
family  of  tools  appear  to  be  computer-based  agents  that  are  capable  of  communicating 
within  a  virtual  environment  of  the  real  world.  From  2001  onward  the  venue  of  the 
Workshop  moved  from  the  West  Coast  to  Washington,  and  in  2003  the  sponsorship  was 
taken  overby  ONR’s  Littoral  Combat/Power  Projection  (FNC)  Program  Office  (Program 
Manager:  Mr.  Barry  Blumenthal).  Themes  and  keynote  speakers  of  past  Workshops  have 
included: 

1999:  ‘ Collaborative  Decision  Making  Tools’ 

Vadm  Jerry  Tuttle  (USN  Ret.);  LtGen  Paul  Van  Riper  (USMC  Ret.); 

Radm  Leland  Kollmorgen  (USN  Ret.);  and.  Dr.  Gary  Klein  (Klein 

Associates) 

2000:  LThe  Human-Computer  Partnership  in  Decision-Support’ 

Dr.  Ronald  DeMarco  (Associate  Technical  Director,  ONR);  Radm  Charles 

Munns;  Col  Robert  Schmidle;  and,  Col  Ray  Cole  (USMC  Ret.) 

2001:  ‘ Continuing  the  Revolution  in  Military  Affairs’ 

Mr.  Andrew  Marshall  (Director,  Office  of  Net  Assessment,  OSD);  and, 

Radm  Jay  M.  Cohen  (Chief  of  Naval  Research,  ONR) 


2002:  ‘ Transformation  ...’ 
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Vadm  Jerry  Tuttle  (USN  Ret.);  and,  Steve  Cooper  (CIO,  Office  of 
Homeland  Security) 

2003:  ‘ Developing  the  New  Infostructure ’ 

Richard  P.  Lee  (Assistant  Deputy  Under  Secretary,  OSD);  and,  Michael 
O’Neil  (Boeing) 

2004:  ‘ Interoperability ’ 

MajGen  Bradley  M.  Lott  (USMC),  Deputy  Commanding  General, 
Marine  Corps  Combat  Development  Command;  Donald  Diggs,  Director, 
C2  Policy,  OASD  (Nil) 


Copies  of  the  proceedings  of  past  Workshops  are  available  free  of  charge  from: 

CAD  Research  Center  (Bdg.l  17T),  Cal  Poly,  San  Luis  Obispo,  CA  93407 
(Attn.:  ONR  Workshop  Proceedings) 
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Opening  Remarks 

as  a  Foreword  to  the  6th  Annual  Office  of  Naval  Research  (ONR)  Workshop 

Good  morning  and  welcome  to  this  6th  annual  Office  of  Naval  Research  Collaborative  Decision- 
Support  Systems  Conference  and  Workshop.  I  am  Jens  Pohl,  Executive  Director  of  the 
Collaborative  Agent  Design  Research  Center  at  California  Polytechnic  State  University,  which  we 
always  refer  to  as  Cal  Poly,  San  Luis  Obispo.  We  have  had  the  honor  of  hosting  this  conference 
since  1999,  and  I  thank  you  for  your  participation  this  year.  I  believe  we  again  have  an  excellent 
group  of  presenters  for  these  two  days  and  we  can  all  look  forward  to  a  very  stimulating 
conference. 

Perhaps  I  should  start  off  by  saying  a  few  words  about  the  purpose  of  these  conferences.  First  and 
foremost  these  conferences  are  intended  to  help  us  shape  an  understanding  and  vision  of  the  rapidly 
advancing  information  technology,  advances  for  which  we  appear  to  have  an  increasing  need.  The 
underlying  reasons  for  this  need  and  the  kind  of  capabilities  that  the  technology  can  provide  us  with 
are  the  subject  of  the  next  two  days.  We  are  in  fact  at  the  beginning  of  a  paradigm  shift, 
transitioning  our  view  of  computers  as  dumb  data  processing  devices  to  collaborative  partners  with 
some  level  of  intelligence.  The  appropriate  application  of  this  powerful  new  technology  involves  all 
of  us  in  a  team  effort  of  major  proportions.  Therefore  this  conference  brings  together 
representatives  from  three  communities  that  have  an  important  stake  in  information  technology. 
First,  the  military  and  civilian  users  who  use  information  technology  as  a  critical  decision  making 
capability.  Second,  the  government  agencies  that  support  the  development  and  integration  of 
information  technology  and  that  includes  the  government  laboratories  and  I  guess  I  would  like  to 
include  in  that  also  the  universities  that  are  conducting  research.  And  third,  industry,  which  actually 
develops  most  of  the  information  technology  products. 

For  the  past  two  years  this  conference  has  been  sponsored  by  Mr.  Barry  Blumenthal,  program 
manager  of  the  Littoral  Combat  Power  Projection  Full  Naval  Capabilities  (FNC)  Program.  Barry, 
thank  you  for  your  continuing  support  in  sponsoring  the  conference  again  this  year. 

At  this  point  it  was  going  to  be  my  very  genuine  pleasure  to  introduce  to  you  the  person  who 
conceived  this  conference  series  more  than  six  years  ago.  Dr.  Phillip  Abraham.  Sadly,  Phil  became 
ill  a  few  days  ago.  He  called  me  to  say  that  on  the  advice  of  his  doctor  he  could  not  attend  the 
conference  this  week.  Phil  Abraham  foresaw  that  we  were  at  the  threshold  of  a  new  generation  of 
computer  software,  with  potential  capabilities  far  exceeding  those  that  were  in  existence  in  1998. 
All  I  can  say  is,  Phil,  how  right  you  were  and  please  recover  quickly  there  is  still  a  great  deal  to 
accomplish. 

You  notice  the  word  collaboration  in  the  title  of  the  conference  series  and  also  in  the  name  of  our 
research  center  at  Cal  Poly,  San  Luis  Obispo.  Recently  I  received  a  telephone  call  from  a  gentleman 
whose  name  I  was  familiar  with,  although  I  had  not  met  him  previously.  However,  I  had  read  some 
of  his  papers.  He  came  straight  to  the  point,  wanting  to  know  the  significance  of  the  word 
collaboration  when  used  in  conjunction  with  decision- support  software.  He  asked:  “How  can 
collaboration  by  software  agents  lead  to  problem  solving?”  His  question  took  me  a  little  by 
surprise  and  I  had  to  gather  my  thoughts  before  replying.  My  reply  was  in  two  parts.  First,  the  use 
of  the  word  collaboration  suggests  a  need  to  view  a  problem  situation  from  several  points  of  view. 
It  further  suggests  a  degree  of  uncertainty  and  a  likelihood  of  conflicting  viewpoints.  In  other 
words,  the  final  decision  is  unlikely  to  be  an  optimum  solution  but  rather  an  acceptable  solution. 
Therefore,  there  is  a  need  for  negotiation  in  a  collaborative  environment.  Second,  the  computer 
environment  is  really  a  virtual  environment.  It  is  a  virtual  representation  of  our  human  environment. 
I  readily  admit  that  today  this  virtual  environment  is  still  a  far  cry  from  the  complexity  and  richness 
of  the  human  environment.  However,  that  is  changing  and  those  changes  will  be  the  focus  of  the 
presentations  and  discussions  of  the  next  two  days.  Computer  software  is  rapidly  gaining  in 
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capabilities  and  there  is  no  question  in  my  mind  that  we  are  rapidly  transitioning  to  a  very  powerful 
virtual  decision-support  environment.  I  further  believe  that  much  of  the  power  of  this  virtual 
environment  will  depend  on  the  ability  of  its  various  intelligent  components,  we  call  them  agents 
these  days,  to  collaborate  with  each  other  and  us  human  users.  This  then  leads  me  into  my 
introductory  presentation  for  this  year's  conference,  Interoperability  and  the  Need  for  Intelligent 
Software. 


Jens  Pohl,  Executive  Director 

Collaborative  Agent  Design  Research  Center  (CADRC), 

California  Polytechnic  State  University  (Cal  Poly),  San  Luis  Obispo 

Quantico,  September  8,  2004 
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Sixth  Annual  ONR  /  CADRC 
Decision-Support  Workshop 

September  8-9,  2004,  Quantico,  Virginia 


The  Office  of  Naval  Research 

and 

The  Collaborative  Agent  Design  Research  Center 

Cal  Poly,  San  Luis  Obispo 

"Interoperability" 

War  Fighting  and  Homeland  Security  Expectations  in  a  Net-Centric  Decision-Support  Environment 

. Architectural  Issues  of  the  Global  Information  Grid  (GIG) 

. Multilateral  Interoperability  Programme  (MIP)  and  C2IEDM 

.  Taxonomies,  Logical  Data  Models,  and  Ontologies 

.  Coalition  Interoperability  at  the  'Information'  Level 

.  Collaborative  Intelligent  Software  Agents 

.  The  Communication  Infrastructure 

.  Government  Plans,  Initiatives,  and  Obstacles 


Wednesday,  September  8: 


Time 

Activity 

7:15 

Check-in  and  Registration  Begins 

Registration  Desk  open  from  7:15  AM  to  5:00  PM 

8:15  -  8:30 

Opening  Remarks  and  Welcome 

Dr.  Jens  Pohl,  Executive  Director,  Collaborative  Agent  Design  Research 

Center,  Cal  Poly,  San  Luis  Obispo,  CA 

8:30  -  8:45 

Why  this  Conference? 

Dr.  Phillip  Abraham,  Naval  Research  Laboratory,  Physical  Acoustics 
Branch,  Washington,  DC 

8:45  -  9:45 

Introduction  of  Conference  Theme:  "Interoperability  and  the  Need  for 
Intelligent  Software" 

Dr.  Jens  Pohl,  Executive  Director,  Collaborative  Agent  Design  Research 

Center,  Cal  Poly,  San  Luis  Obispo,  CA 

9:45  -  10:00 

Break 

__  Collaborative  Agent  Design  Research  Center 

f  A  1  OC\Fy  California  Polytechnic  State  University  .  /"^Al  CJ 

\  V  -  1  San  Luis  Obispo,  CA  93407  *^|l  f*  ^  Ml  J 

www.cadrc.calpoly.edu 
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Wednesday,  September  8  (continued): 


Time 

Activity 

10:00  -  10:30 

"Delivering  Joint  and  Coalition  Interoperability  at  the  Information 
Level" 

LCol.  Jacques  Hamel,  The  Canadian  Forces,  PM  ISTAR,  Ottawa,  Canada 

10:30  -  11:00 

"  Levels  of  Interoperability  " 

Dr.  Peter  C.  Bahrs,  IBM  Corporation,  Austin  TX  and  Dr.  Christopher 
Codella,  IBM  Corporation,  Hawthorne  NY 

11:00  -  11:30 

"Interoperability  Cost  Estimation" 

Dr.  Conrad  Strack,  CSCI,  Springfield,  VA 

11:30  -  12:00 

"  Information  and  Global  Integration" 

Col.  Robert  Morris  (USA),  Director,  Decision  Superiority  Dept.,  JFCOM, 
Suffolk,  VA 

12:00  -  1:15 

Lunch 

1:15  -  1:45 

"The  C2  Col  as  the  Foundation  for  Joint,  Multinational,  and  Inter¬ 
agency  Interoperability  " 

Mr.  Erik  Chaum,  Naval  Sea  Systems  Command,  Warfare  Center,  Division 
Newport.  RI 

1:45  -  2:15 

"Data  Mediation  Services  Based  on  the  C2IEDM  -  Migration  of  Legacy 
Systems  into  Service-Oriented  Architectures  " 

Dr.  Andreas  Tolk,  Virginia  Modeling  Analysis  and  Simulation  Center,  Old 
Dominion  University,  Norfolk,  VA 

2:15  -  2:45 

"Battle  Management  Language  -  Enabling  Semantic  Interoperability" 

Dr.  Michael  Hieb,  ALION  Science  and  Technology,  McLean,  VA 

2:45  -  3:00 

Break 

3:00  -  3:30 

"Semantic  Mediation  Tools  for  Interoperability" 

Ms.  Mala  Mehrotra,  Pragati,  Inc.,  San  Jose,  CA 

3:30  -  4:00 

"Generative  Ontologies  for  Extracting  Concepts  from  Text  Documents" 

Dr.  David  W.  Aha,  Naval  Research  Laboratory,  Washington,  DC 

4:00  -  4:30 

"Challenging  Old  Assumptions  in  Global  Information  Access" 

Dr.  Van  Parunak,  Altarum  Institute,  Ann  Arbor,  MI 

4:30  -  5:00 

"The  Multilateral  Interoperability  Programme  (MIP)  -  Coalition 
Sharing  of  Information  in  Context" 

Mr.  Paul  Ulrich,  Shonborn  Becker  Systems,  Inc.,  Union,  NJ 

5:00 

(CLOSE  DAY  ONE) 

5:00  -  7:00 

7:00  -  9:00 

No  Host  Social 

Speakers'  Dinner  In  the  Waller  Room  (by  invitation) 
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Thursday,  September  9: 


7:15  -  12:00  Check-in  and  Registration  Continues 

Registration  Desk  open  from  7:15  AM  to  noon 


7:55  -  8:00  Announcements 

Dr.  Jens  Pohl,  Executive  Director,  Collaborative  Agent  Design  Research 
Center,  Cal  Poly,  San  Luis  Obispo,  CA 

8:00  -  8:45  Keynote:  "Posturing  to  Exploit  the  Power  of  Emerging  Technology 

MGen  Bradley  M.  Lott  (USMC),  Deputy  Commanding  General,  Marine 
Corps  Combat  Development  Command,  Quantico,  VA 

9:00  -  9:45  Keynote:  "Information  Integration  and  Decision  Support" 

Mr.  Donald  Diggs,  Director,  C2  Policy,  OASD  (Nil),  Washington,  DC 

9:45  -  10:00  Break 

10:00  -  10:30  " Coalition  Command  and  Control:  The  COSMOS  ACTD  as  an  Agent  for 

Change" 

Col.  Kevin  Jordan  (USMC  ),  PACOM 

10:30  -  11: 00  "Network  Security  Issues  for  the  GIG" 

Dr.  Scott  Hansen,  Northrop  Grumman  Defense  Missile  Systems,  Reston,  VA 

11: 00-  11:30  "Global  Information  Integration  and  Decision  ( GIID)  Portfolio. " 

Mr.  Peter  Trask,  Johns  Hopkins  University,  APL,  Laurel,  MD 

11:30  -  12:00  "Cross  Agency  Collaboration  -  JWID  '04  Experience" 

Mr.  David  Waxman,  IBM,  Hawthorne,  NY 

12:00  -  1:15  Lunch 

1:15  -  1:45  "Game  Theoretic  Models  for  Reliable  Optimal  Routing  for  Data 

Aggregation  in  Wireless  Sensor  Networks" 

Dr.  S.S.  Iyengar,  Roy  Paul  Daniels  Professor,  Louisiana  State  University, 
Baton  Rouge,  LA 

1:45  -  2:15  "Automated  Decision  Support  for  Architectures" 

Dr.  Steven  Wartik  and  Dr.  Francisco  Loaiza,  Institute  for  Defense 
Analyses,  Alexandria,  VA 

2:15-2:45  "  Use  ofXML-Based  C2IEDM  Interchange  and  XML  Tactical  Chat  (XTC) 

for  Global  Interoperability" 

Dr.  Don  Brutzman,  Naval  Postgraduate  School,  Monterey,  CA 

2:45  Workshop  Wrapup 

Dr.  Jens  Pohl,  Executive  Director,  Collaborative  Agent  Design  Research 
Center,  Cal  Poly,  San  Luis  Obispo,  CA 

(CLOSE  DAY  TWO) 
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Office  of  Naval  Research  (ONR).  For  the 
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the  eight  years  before  that,  starting  in 
1994,  he  managed  the  ONR  Science  and 
Technology  (S&T)  Logistics  Program.  A 
major  endeavor  during  these  years  was  the 
introduction  of  S&T  projects  in  a  program 
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operations  are  the  SEAWAY  and  LOGGY 
projects  that  have  received  support  from 
both  the  Navy  and  the  Marine  Corps),  Naval 
Facilities  (  the  major  thrusts  in  this  area 
were  the  operation  of  the  naval  bases,  the 
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to  the  needs  of  that  level),  and  Integration 
(the  goal  here  is  the  integration  of  all  the 
systems  on  a  single  navy  platform,  a 
squadron,  a  battle  group,  a  fleet,  &c.,  that 
will  result  in  the  highest  achievable  state  of 
readiness.  A  current  project,  "Mission 
Readiness  Analysis",  addresses  the 
challenge  of  systems  integration  on  a  single 
platform). 

Dr.  Abraham  joined  the  Office  of  Naval 
Research  in  1989  as  a  member  of  the 
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or  actively  targets  in  regions  of  the  ocean 
that  are  contaminated  by  random 
distributions  of  biological  and  other 
scatterers. 


In  1974  Dr.  Abraham  started  working  at  the 
Naval  Underwater  Sound  Laboratory  in  New 
London,  Connecticut.  There  his  research 
dealt  with  underwater  acoustics,  focusing 
on  detection  and  localization  of  underwater 
targets.  Among  other  topics,  he  determined 
the  influence  of  size  on  magnetic  anomaly 
detection  (MAD)  of  ferromagnetic  targets 
(such  as  submarines).  In  addition  he,  and 
Dr.  H.  Moses,  used  inverse  scattering  theory 
to  generate  new  families  of  sound  velocity 
profiles  (in  the  ocean)  for  which  the  wave 
equation  has  exact  solutions.  These  were 
useful  later  on  in  determining  acoustic  wave 
propagation  in  the  arctic  ice  cap.  This  work 
also  led  to  concurrent  results  for  potentials 
appearing  in  the  Schrodinger  equation  of 
Quantum  Mechanics.  One  of  these 
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harmonic  oscillator  potential,  has  been 
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de-confliction  and  air  vehicle  management. 
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initiative  planning,  and  knowledge 
management  (e.g.,  intelligent  lessons 
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Graphics  Specification  Task  Group.  X3D  is 
the  third-generation  version  of  the  Virtual 
Reality  Modeling  Language  (VRML) 
international  standard.  He  further  directs 
development  of  the  virtual  reality  transfer 
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educational  institutions  around  Monterey 
Bay.  He  also  leads  the  SIGGRAPH  Online 
effort,  which  will  record  and  publish  over 
100  hours  of  instructional  video,  papers  and 
slidesets  via  Web-based  multimedia 
distribution. 

Dr.  Brutzman  is  a  retired  submarine  officer 
who  has  conducted  testing  of  advanced 
capability  underwater  equipment.  Current 
research  work  includes  the  development  of 
underwater  robot  software,  in  combination 
with  comprehensive  virtual-world  modeling 
of  underwater  hydrodynamics,  sonar  and 
robot  hardware  response.  This  physics- 
based  virtual  world  development  supports 
the  Acoustic-Radio  Interactive  Exploratory 
Server  (ARIES),  a  highly  capable  fourth- 
generation  Autonomous  Underwater  Vehicle 
(AUV)  designed,  built  and  operated  at  NPS. 
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Multilateral  Interoperability  Programme 
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duty  he  attended  Management  of 
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retired  from  the  Reserves  in  1998. 

He  and  his  wife  Meryl  live  in  Portsmouth, 
Rhode  Island. 


Dr.  Christopher  F.  Codella 
Deputy  Chief  Technology  Officer 
IBM 

Christopher  F.  Codella  is  Deputy  Chief 
Technology  Officer  for  IBM  Federal, 
Software  Group.  Dr.  Codella  received  a  B.S. 
degree  from  Rutgers  University  in  1977,  an 
M.S.E.  from  the  University  of  Michigan  in 
1978,  and  a  Ph.D.  from  Cornell  University  in 
1984,  all  in  Electrical  Engineering.  His 
dissertation  work  focused  on  fabrication, 
characterization  and  numerical  simulation  of 
compound  semiconductor  field-effect 
transistors.  From  1979  to  1989  he  worked 
at  IBM  in  East  Fishkill,  NY  and  Yorktown 
Heights,  NY  doing  NMOS  and  CMOS  device 
and  process  design  using  numerical 
simulation  and  analysis,  and  developing 
device  models  for  computer  based  circuit 
and  chip  design. 
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Member  in  the  Computer  Science 
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software  for  collaborative  virtual 
environments.  During  1996  he  worked  in 
the  IBM  Consulting  Group  on  assignment, 
developing  a  framework  for  reuse  of  models 
and  code  across  the  services  sectors. 
Recently  he  was  senior  manager  of  the 
Enterprise  Middleware  department,  which 
does  research  and  advanced  development 
in  object-oriented  software  technology, 


distributed  systems,  reusable  software 
components  and  component  architecture. 
The  group  has  contributed  many  innovative 
software  technologies  that  have  become 
part  of  IBM's  middleware  products  including 
WebSphere,  Component  Broker,  and  MQ 
Series.  He  received  IBM's  Outstanding 
Technical  Achievement  Award  for  his 
contributions  to  Enterprise  Java.  Before 
joining  IBM  Federal,  he  was  on  a  one-year 
assignment  to  the  Research  Division 
headquarters  staff  where  he  led  the 
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corporate  technical  strategy. 
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Arts  in  National  Security  and  Strategic 
Studies. 

In  March  2003,  Mr.  Diggs  retired  from  the 
Navy  after  his  assignment  to  the  Office  of 
the  Secretary  of  Defense  as  Acting  Director 
for  C2  Policy  overseeing  a  variety  of 
Department  of  Defense  C2  issues  including 
development  of  national  C2  architectures 
and  implementing  C2  policy  for  net-centric 
operations.  Fie  was  the  primary  OSD 
advocate  for  Executive  Agent  responsibilities 
supporting  the  White  Flouse  Military  Office 
with  oversight  of  a  wide  range  of  DoD 
command  and  control  assets.  In  the 
aftermath  of  September  11th,  he  was 
responsible  for  over  $500  million  of 
supplemental  funding  which  led  to 
improvements  in  Presidential,  Secretary  of 
Defense,  and  other  Senior  Leader  fixed  and 
mobile  communications  infrastructures.  Fie 
also  led  the  efforts  of  the  Services  and 
multiple  agencies  in  the  design,  integration 
and  deployment  of  critical  and  sensitive  C2 
capabilities  to  multiple  operational  locations 
across  the  greater  National  Capital  Region. 

Mr.  Diggs  is  currently  active  in  development 
of  National  and  Department  of  Defense 
Command  and  Control  concepts  in  support 
of  the  nation's  senior  leadership  and  in 


support  of  both  nuclear  and  non-nuclear 
strike  and  defenses. 


Lieutenant-Colonel  Jacques  Hamel, 
CD,  Eng 

The  Canadian  Forces,  PM  ISTAR 

LCol  Jacques  Flamel  joined  the  Canadian 
Forces  in  1977  as  an  Engineer  Officer.  Fie 
Graduated  in  1982  form  the  Royal  Military 
College  in  Kingston  with  an  Flonour  Degree 
in  Engineering  Physics.  In  1982  he  joined 
the  5e  Regiment  du  genie  de  combat  (5th 
Combat  Engineer  Regiment)  in  Valcartier, 
where  he  served  over  a  number  of 
regimental  assignment  as  a  Troop 
Commander,  Adjutant,  Squadron 
Commander  and  Deputy  Commanding 
Officer  until  1990. 

From  1991  to  1993  LCol  Flamel  served  in 
National  Defence  HQ  on  the  J3  Engineer 
Staff  as  a  Project  Director  for  a  wide  range 
on  Combat  Engineering,  Command  and 
Control  automation  and  Geomatics  Capital 
Projects  and  as  the  J3  Engineer- 
Sustainment  on  the  Joint  Staff.  In  1994  LCol 
Flamel  was  appointed  G3  Plans  In  Army  HQ 
where  he  was  responsible  for  all 
international  and  contingency  planning  for 
the  Canadian  Army. 

In  1997  LCol  Flamel  was  appointed  to  the 
Directorate  of  Army  Doctrine  as  the  section 
head  responsible  for  force  protection 
doctrine  and  as  Acting  Director  of  Army 
Doctrine  during  1998.  In  1999  LCol  Flamel 
Joined  the  Army  Strategic  Concept  staff  as 
the  Director  of  the  Army  Experimentation 
Centre  and  he  became  the  Canadian  Flead 
of  delegation  to  the  ATCCIS  study. 

From  2000  to  2003  LCol  Flamel  was  the 
Program  Manager  of  the  Canadian  Land 
Force  Command  and  Control  Information 
System  (LFC2IS)  and  internationally  acted 
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as  the  Chairman  of  the  MIP  Data  and 
Procedure  Working  Group. 

In  2003  LCol  Hamel  was  appointed  to  his 
current  appointment  of  Project  Manager 
Intelligence  Surveillance,  Target  Acquisition 
and  Reconnaissance  (ISTAR)  Omnibus 
where  he  is  responsible  for  the 
implementation  of  the  Army  C4ISR  Projects. 
Internationally  he  is  active  in  the  CANUS 
C4ISR  interoperability  and  in  the  MAJIIC 
program. 

LCol  Hamel  is  a  Professional  Engineer  with 
I'Ordre  des  Ingenieur  du  Quebec,  a 
graduate  of  the  Canadian  Land  Force 
Command  and  Staff  College  in  Kingston,  of 
the  UK  Royal  Military  College  of  Science  in 
Schrivenham  and  of  the  UK  Army  Command 
and  Staff  Course  in  Camberley. 


Dr.  D.  Scott  Hansen 
Assistant  Vice  President  for  C4I 
Northrop  Grumman 

Dr.  Hansen  holds  a  B.S  in  Engineering 
Physics  from  Oregon  State  University,  a  MS 
in  Applied  Mathematics  from  UC,  San  Diego, 
and  a  Ph.D  in  Oceanography  from  Scripps. 
He  presently  holds  the  position  of  Senior 
Program  Manager  at  Northrop  Grumman 
Corporation. 

Dr.  Hansen  is  participating  in  several 
strategic  initiatives  related  to  DoD  and  DHS 
program  development  as  DoD  and  civil 
sectors  of  the  government  develop  US 
Homeland  Security  and  Defense  programs. 
Dr.  Hansen  is  also  assisting  various 
DoD/Civil  Wireless  initiatives  in  defining 
program  scope  and  technical  concepts.  Dr. 
Hansen  is  working  initiatives  between  DoD 
and  HLS/DHS  netcentric  activities.  Many 
issues  related  to  fundamentals  privacy  are 
security  are  being  studied  as  part  of  these 
efforts. 


Before  joining  Northrup  Grumman,  Dr. 
Hanson  was  Senior  Engineer  with  Science 
Applications  International  Corporation 
where  he  participated  technically  and  in 
varying  management  roles  in  a  wide  range 
of  C4ISR  and  Network  Centric  Warfare 
Programs  supported  by  state  of  the  Art 
Modeling  and  Simulation  Systems.  These 
programs  include  the  Defense  Advanced 
Research  Projects  Agency  (DARPA) 
Simulation,  Evaluation  and  Management  of 
Mobile  and  fixed  Networking  technologies 
being  used  to  support  analyses  for  the 
Future  Combat  System,  Objective  Force, 
Interim  Brigade  Combat  Teams,  Joint 
Virtual  Battlespace,  Ship-to-Objective 
Maneuver  and  several  related  activities 
supporting  defining  standards  and 
architectures  for  the  Joint  Tactical  Radio 
System  in  warfighting,  and  Homeland 
Security  and  Defense  roles. 

Dr.  Hansen  has  also  been  heavily  involved 
in  assessing  and  developing  Military, 
Interagency  and  Civilian  preparedness  and 
response  capabilities  for  NBCRE  operations. 
Dr.  Hansen  has  participated  in  National  and 
International  Congressionally  mandated 
assessments  of  the  National  infrastructure 
to  mitigate  the  effects  of  NBCRE  asymmetric 
attacks  and  other  terrorists  operations  for 
Domestic  and  International  facilities.  In 
particular,  Dr.  Hansen  has  been  involved  in 
assessing  (nationally  and  internationally) 
and  developing  draft  policies,  processes  and 
C4ISR  infrastructure  in  government, 
military,  business  and  health  care  sectors 
that  enable  responding  to  these  classes  of 
threats.  Dr.  Hansen  was  the  author  of  the 
C4ISR  and  Telecommunications  sections  of 
the  Report  to  the  National  Guard  Bureau 
Weapons  of  Mass  Destruction  report  to 
Congress.  Also  in  this  arena,  Dr.  Hansen,  is 
an  expert  in  operational  interoperability 
between  Napoleonic  and  Incident  Command 
System  staff  organizations. 
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Prior  to  being  involved  with  the  Joint 
Countermine  ACTD  initiated  in  1995,  Dr. 
Hansen  was  heavily  involved  in  developing 
the  US  Navy's  Mine  Warfare  C4ISR 
Architecture.  In  support  of  this  effort  Dr. 
Hansen  coordinated  closely  with  N6,  N85, 
Program  Executive  Officer  for  Mine  Warfare 
(PEO-MIW),  Commander  Mine  Warfare 
Command  (CMWC),  Naval  Doctrine 
Command,  Naval  Command  and  Control 
Oceanographic  System  Command,  Coastal 
System  Command  and  several  components 
of  SPAWAR  to  develop  an  inclusive 
architecture  under  the  Copernican 
guidelines. 

Dr.  Hansen  also  led  the  Demonstration  and 
Integration  team  as  the  Chief  Scientist  for 
the  US  Navy  for  the  Air  Defense  Initiative 
(ADI).  This  Joint  CONUS  Defense  Program, 
part  of  the  Strategic  Defense  Initiative,  with 
extensive  participation  from  SPACECOM, 
NORAD,  PACOM  and  USACOM  culminated  in 
a  series  of  dedicated  and  leveraged  field 
experimental  programs  where  Dr.  Hansen 
served  as  Chief  Scientist  and  directed  all 
phases  of  these  complex  operations.  Much 
of  the  technical  effort  for  this  program 
focused  on  data  fusion  of  dissimilar  C4ISR 
phenomenology.  Specialized  correlation 
algorithms  were  implemented  within  the 
Joint  Maritime  Command  and  Information 
System  (JMCIS)  to  support  many  of  these 
field  demonstrations  and  laboratory 
analysis. 

At  BBN  Systems  and  Technology 
Corporation  from  1984  to  1988,  Dr.  Hansen 
participated  and  managed  efforts  related  to 
theoretical  and/or  field  studies  for  active 
and  passive  detection  of  undersea  platforms 
from  surface  and  subsurface  detection 
systems.  These  studies  generally  included 
threat  envelope  assessments,  "wet"  end 
sensitivity/performance  considerations, 
ambient  noise/reverberation  issues,  signal 
processing  performance,  and  finally 
operator/display  performance.  In  support  of 


these  studies  Dr.  Hansen  led  teams  of 
analysts  and  system  implementors  for 
prototype  detection  systems.  Programs 
involved  in  these  efforts  included  Low 
Frequency  Active  (LFA)  including  its  Low 
Low  variant  (LLFA),  Fixed/Fixed  I-III, 
Glenngarry  I  and  II  and  Overbid  Leo  for 
active  systems  and  primarily  the  Fixed 
Distributed  System  (FDS)  for  passive 
systems.  Dr.  Hansen  and  the  teams  he  led 
researched  the  performance  envelope  of 
advanced  signal  processing 
systems/algorithms  including  varying 
waveforms,  normalization  approaches, 
reverberation  cancellation  filtering  and 
continuous  wave  barrier  approaches  for 
active  systems.  For  passive  systems  team 
efforts  included  signature  analysis  of  special 
platforms,  Adaptive  and  Conventional 
Beamforming,  array  design,  broadband 
cross  and  autocorrelation  systems  and 
narrowband  phase  tracking. 


Dr.  Michael  Hieb 
Assistant  Vice  President  for  C4I 
Programs,  Alion  Science  and 
Technology 

Michael  Hieb  is  an  Assistant  Vice  President 
for  C4I  Programs  for  Alion  Science  and 
Technology.  Dr.  Hieb  is  currently  an 
Architect  for  the  Army  SIMCI  OIPT.  He 
received  his  Ph.D.  in  Information 
Technology  at  George  Mason  University  in 
1996  and  performed  his  doctoral  research 
at  the  GMU  Center  for  Excellence  in  C3I. 
Dr.  Hieb  received  his  MS  degree  in 
Engineering  Management  from  George 
Washington  University  and  his  BS  degree  in 
Nuclear  Engineering  from  the  University  of 
California  in  Santa  Barbara.  He  has 
published  over  50  papers  in  the  areas  of 
M8iS  integration  with  C4I  and  Machine 
Learning.  Previously,  he  worked  as  a 
Nuclear  Engineer  for  General  Electric. 
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Dr.  S.S.  Iyengar 

Roy  Paul  Daniels  Professor 

Lousiana  State  University 

Dr.  S.  S.  Iyengar  is  the  Chairman  and  Roy 
Paul  Daniels  Chaired  Professor  of  Computer 
Science  at  Louisiana  State  University  and  is 
also  Satish  Dhawan  Chaired  Professor  at 
Indian  Institute  of  Science.  He  has  been 
involved  with  research  in  high-performance 
algorithms,  data  structures,  sensor  fusion, 
data  mining,  and  intelligent  systems  since 
receiving  his  Ph.D.  degree  (in  1974  at 
Mississippi  State  University)  and  his  M.S. 
from  the  Indian  Institute  of  Science  (1970). 
He  has  directed  over  30  Ph.D.  candidates, 
many  of  whom  are  faculty  at  major 
universities  worldwide  or  scientists  or 
engineers  at  national  labs/industry  around 
the  world.  His  publications  include  13 
books  (authored  or  coauthored,  edited; 
Prentice-Hall,  CRC  Press,  IEEE  Computer 
Society  Press,  John  Wiley  &  Sons,  etc.)  and 
over  300  research  papers  in  refereed 
journals  and  conference  in  areas  of  high- 
performance  parallel  and  distributed 
algorithms  and  data  structures  for  image 
processing  and  pattern  recognition,  and 
distributed  data  mining  algorithms  for 
biological  databases.  His  books  have  been 
used  by  researchers  at  Purdue,  University  of 
Southern  California,  University  of  New 
Mexico,  etc.  at  various  times.  He  was  a 
visiting  professor  at  the  Jet  Propulsion 
Laboratory-Cal.  Tech,  Oak  Ridge  National 
Laboratory,  the  Indian  Institute  of  Science, 
and  at  the  University  of  Paris  and  other 
places.  He  has  been  on  the  prestigious 
National  Institute  of  Health-NLM  Review 
Committee,  in  the  area  of  Medical 
Informatics  for  4  years. 

Dr.  Iyengar  was  the  winner  of  the  IEEE 
Computer  Society  Technical  Achievement 
Award  for  Outstanding  Contributions  to 
Data  Structures  and  Algorithms  in  Image 
Processing  and  Sensor  Fusion  Problems. 
This  is  the  most  prestigious  research  award 


from  IEEE  Computer  Society.  Dr.  Iyengar 
was  awarded  the  LSU  Distinguished  Faculty 
Award  for  Excellence  in  Research,  the  Hub 
Cotton  Award  for  Faculty  Excellence,  and 
the  LSU  Tiger  Athletic  Foundation  Teaching 
Award  in  1996.  He  has  been  a  consultant 
to  several  industrial  and  government 
organizations  (JPL,  NASA  etc.).  In  1999, 
Professor  Iyengar  won  the  most  prestigious 
research  award  titled  Distinguished 
Research  Award  and  a  university  medal  for 
his  research  contributions  in  optimal 
algorithms  for  sensor  fusion/image 
processing. 

He  is  also  a  Fellow  of  ACM,  a  Fellow  of  the 
IEEE,  a  Fellow  of  AAAS,  IEEE  Distinguished 
Visitor,  etc.  He  received  the  Prestigious 
Distinguished  Alumnus  Award  from  Indian 
Institute  of  Science,  Bangalore  in  2003. 
Also,  Elected  Member  of  European  Academy 
of  Sciences  (2002).  He  is  a  member  of  the 
New  York  Academy  of  Sciences.  He  has 
been  the  Program  Chairman  for  many 
national/international  conferences.  He  has 
given  over  60  plenary  talks  and  keynote 
lectures  at  numerous  national  and 
international  conferences. 


Colonel  Kevin  B.  Jordan 
USMC 

Colonel  Jordan  graduated  from  the 
University  of  Pennsylvania  in  1972  with  a  BA 
in  psychology,  and  was  commissioned  a 
second  lieutenant  through  Officer  Candidate 
School  in  1976.  He  has  attended 
Communication  Officer  School,  the  Marine 
Corps  Command  and  Staff  College,  and  the 
Armed  Forces  Staff  College.  He  graduated 
with  highest  distinction  from  the  Naval  War 
College  in  June  1996  with  an  M.A.  in 
National  Security  Studies.  He  was  promoted 
to  his  current  grade  in  October  1998. 

Colonel  Jordan's  assignments  over  the  past 
25  years  include  serving  as  Commanding 
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Officer,  Marine  Communications 
Detachment,  USS  Blue  Ridge;  CINC 
Communications  Officer,  U  .S.  Central 
Command  during  Operation  Desert 
Shield/Storm;  Inspector/Instructor  for  the 
6th  Communication  Battalion  at  Ft. 
Schuyler,  NY;  Central  Command  Desk 
Officer  in  the  Current  Operations  Division  of 
the  Communications  Directorate  (J6)  of  the 
Joint  Staff;  Assistant  Chief  of  Staff  for 
Communications  (G6)  for  the  Marine  Forces 
Reserve  in  New  Orleans,  LA;  Commanding 
Officer,  Headquarters  &  Service  Battalion, 
Marine  Forces  Pacific;  Assistant  Chief  of 
Staff/G6,  Marine  Forces  Pacific.  He  served 
concurrently  as  the  G-6  for  Marine  Forces 
Central  Command  as  the  senior 
communications  strategist  and  war  planner 
for  Operation  Enduring  Freedom  (OEF)  and 
Operation  Iraqi  Freedom  (OIF),  with 
additional  responsibility  and  oversight  for 
large  C4  commercialization  projects  in 
Djibouti  and  Iraq.  He  is  currently  in  charge 
of  Operations  &  Plans  in  the  J6  for  U.S. 
Pacific  Command,  and  concurrently  serves 
as  Operational  Manager  for  the  Coalition 
Secure  Management  and  Operations  System 
(COSMOS)  Advanced  Concept  Technology 
Demonstration  (ACTD). 

Colonel  Jordan's  personal  awards  include 
the  Legion  of  Merit,  Bronze  Star  (2nd 
award),  Joint  Meritorious  Service  Medal  (2nd 
award),  Meritorious  Service  Medal  (2nd 
award),  Navy  Commendation  Medal  (2nd 
award),  and  Navy  Achievement  Medal  (2nd 
award). 

Colonel  Jordan  is  married  to  Dr.  Dianne 
Hirata  Jordan.  They  have  two  sons:  Eamon, 
age  26,  a  graduate  in  electrical  engineering 
from  the  University  of  Pennsylvania  and  an 
Air  Force  IstLt  assigned  to  the  606th  Air 
Control  Squadron  based  in  Spangdalem, 
Germany;  and  Brendan,  age  23,  a  graduate 
in  economics  from  the  University  of 
Pennsylvania,  now  working  for 
Oppenheimer  &  Co.  in  New  York  City. 


Major  General  Bradley  M.  Lott 
Deputy  Commanding  General,  Marine 
Corps  Combat  Development  Command 
(MCCDC) 

Major  General  Lott  is  currently  serving  as 
the  Deputy  Commanding  General,  Marine 
Corps  Combat  Development  Command, 
Quantico,  Virginia.  Additionally,  he  serves  as 
the  Marine  Corps  Principal  Representative  to 
the  Joint  Capabilities  Board,  which  supports 
the  Assistant  Commandant  of  the  Marine 
Corps  and  the  Vice  Chairman  of  the  Joint 
Chiefs  of  Staff  in  carrying  out  their 
responsibilities  with  the  Joint  Requirements 
Oversight  Council. 

General  Lott  was  commissioned  through  the 
Officer  Candidates  School  in  1972  and  after 
completing  The  Basic  School  he  was 
assigned  to  the  2d  Marine  Division  and  later 
with  Force  Troops,  Atlantic.  In  1976,  he  was 
assigned  to  9th  Marine  Regiment,  3d  Marine 
Division. 

During  January  1979,  General  Lott  was 
assigned  to  the  staff  of  Officer  Candidates 
School  while  awaiting  the  start  of 
Amphibious  Warfare  School  (AWS).  Upon 
completion  of  AWS,  he  transferred  to  the 
1st  Force  Service  Support  Group  where  he 
served  as  a  Company  Commander.  In  1982, 
he  was  promoted  to  Major  and  assigned  as 
a  Battalion  Executive  Officer. 

In  1983,  he  was  assigned  to  the  Joint  U.S. 
Military  Assistance  Group-Korea  as  the 
Security  Assistance  Officer  where  he 
managed  the  contracts  and  accounts  for 
major  equipment  and  ammunition 
acquisition  for  the  Republic  of  Korea  Naval- 
Marine  Forces. 

In  1985,  General  Lott  attended  the  Marine 
Corps  Command  and  Staff  College,  followed 
by  an  assignment  in  the  1st  Force  Service 
Support  Group.  After  promotion  to 
Lieutenant  Colonel  in  1989,  he  assumed 
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command  of  MEU  Service  Support  Group  13 
and  deployed  to  the  Western  Pacific  where 
he  participated  in  humanitarian  relief 
operations  in  the  Republic  of  the  Philippines 
and  in  Operations  Desert  Shield  and  Desert 
Storm  in  the  Middle  East. 

Upon  returning  to  CONUS  in  1991,  General 
Lott  was  assigned  as  the  Director,  Materiel 
Division,  Marine  Corps  Logistics  Base, 
Albany,  Georgia  and  then  Commander, 
Defense  Distribution  Depot,  Albany, 
Georgia,  followed  by  attendance  at  the 
Industrial  College  of  the  Armed  Forces. 
Following  graduation  in  1993,  he  was 
promoted  to  Colonel  and  assigned  as  the 
Deputy  Executive  Director,  Strategic 
Programming  and  Contingency  Operations 
at  the  Defense  Logistics  Agency.  During  the 
fall  of  1994,  General  Lott  deployed  to  Haiti 
as  the  Chief  of  Staff,  Joint  Logistics  Support 
Command,  Multi-National  Force.  Following 
this  tour,  he  was  assigned  as  the  Executive 
Assistant  to  the  Deputy  Chief  of  Staff, 
Installations  and  Logistics  at  Headquarters, 
U.S.  Marine  Corps  while  serving 
concurrently  as  the  Director  of  Logistics 
Plans  and  Policy  Analysis. 

In  June  1996,  General  Lott  reported  to  3d 
Force  Service  Support  Group  where  he 
assumed  command  of  3d  Support  Battalion 
and  served  concurrently  as  the 
Commanding  Officer,  FSSG  (Forward). 
Following  command,  he  reported  to  Marine 
Corps  Base,  Camp  Butler  as  the  Assistant 
Chief  of  Staff,  Marine  Corps  Community 
Services.  In  July  1999,  he  was  promoted  to 
Brigadier  General  and  assumed  command  of 
the  First  Force  Service  Support  Group  where 
he  remained  until  June  of  2001.  During  this 
same  period  he  also  served  one  rotation  as 
the  Commanding  General,  Coalition/Joint 
Task  Force,  Kuwait. 

In  July  2001,  General  Lott  took  command  of 
Marine  Corps  Materiel  Command,  Albany, 
Georgia,  later  renamed  Marine  Corps 


Logistics  Command,  and  remained  there 
through  June  of  2003.  He  was  frocked  to 
Major  General  in  September  of  2002. 

General  Lott  holds  a  Bachelor  of  Science 
degree  from  the  University  of  West  Florida 
and  a  Master  of  Science  degree  from  the 
University  of  Southern  California  and  is  a 
graduate  of  the  National  Security  Program 
at  Harvard  University.  His  military 
decorations  include  the  Defense  Superior 
Service  Medal,  Legion  of  Merit  with  gold 
star,  Defense  Meritorious  Service  Medal, 
Meritorious  Service  Medal,  Navy  and  Marine 
Corps  Commendation  Medal,  Army 
Commendation  Medal,  Navy  and  Marine 
Corps  Achievement  Medal,  Combat  Action 
Ribbon,  Joint  Meritorious  Unit  Award,  Navy 
Unit  Citation,  Meritorious  Unit 
Commendation,  and  he  wears  the 
Navy/Marine  Corps  Parachutist  insignia. 


Ms.  Mala  Mehrotra 
President 

Pragati  Synergetic  Research,  Inc. 

Mala  Mehrotra  is  the  President/CEO  of 
Pragati  Synergetic  Research  Inc.,  an  8a 
certified,  small,  woman-owned, 
disadvantaged  business  specializing  in 
research  and  development  in  the  areas  of 
ontology  analysis,  software  engineering  of 
intelligent  systems,  and  JAVA-based  tool 
development.  Ms.  Mehrotra  has  been 
performing  high-end  artificial  intelligence 
research  for  mainly  government  clients  such 
as,  DARPA,  Air  Force,  Navy,  NASA,  NSF.  for 
the  last  14  years. 

Mala  Mehrotra  has  an  M.  S.  degree  in 
Computer  Science  with  concentration 
in  artificial  intelligence  and  parallel 
computing  from  the  College  of  William  and 
Mary  in  VA.  In  addition  she  also  has  an  M.S. 
in  Nuclear  Physics  from  Delhi  University, 
India.  She  has  been  the  main  architect  of 
Pragati's  flagship  product,  Multi-ViewPoint 
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Clustering  Analysis  (MVP-CA)  Tool  which 
partitions  large  and  complex  knowledge- 
based  systems  into  meaningful  units  for  the 
purpose  of  analyzing  them.  MVP-CA  tool 
was  used  in  analyzing  IMMACCS,  a  multi¬ 
agent  system  for  command  and  control, 
results  of  which  have  been  presented  in  the 
ONR  workshop  series  previously. 

Lately  Ms.  Mehrotra  has  been  the  PI  on  two 
SBIR  projects,  one  from  ONR  and  another 
one  from  NASA  Ames. Under  the  ONR 
project  a  prototype  OSRT  (Ontology  Search 
and  Reuse  Tool)  tool  has  been  built,  to 
address  a  number  of  core  reuse  challenges 
for  ontologies.  To  date,  aligning,  mapping 
and  merging  ontologies  are  complicated 
undertakings  that  require  significant  manual 
effort  from  their  designers.  OSRT  achieves 
reuse  by  enabling  users  to  issue 
semantically  rich  queries  against  large 
collections  of  diverse  source  knowledge 
bases.  It  provides  the  user  with  multiple 
views  of  the  query  results  and  a  framework 
to  adapt  those  results  for  reuse  in  a  target 
knowledge  base  under  construction.  In 
another  separately  funded  DOD  effort  Ms. 
Mehrotra  is  also  trying  to  address  reuse 
issues  in  the  context  of  Semantic  Web  OWL 
ontologies  for  CODE  (Collaborative  Ontology 
Development  Environment)  under 
construction  at  IHMC  (Institute  for  Human 
and  Machine  Cognition). 

For  the  NASA  project  Ms.  Mehrotra  is 
developing  an  Iterative  Ontology 
Development  (IOD)  toolkit  as  a  Protege 
plug-in  component.  It  is  a  semi-automated 
information  extraction  tool  that  enables 
analysts  to  rapidly  create  structured 
representations  of  the  information  present 
in  natural  language  text.  Pragati's  existing 
clustering  technology  provides  the 
foundation  for  IOD's  abilities.  Clustering 
brings  together  fragments  of  source  text 
that  are  similar.  By  viewing  the  text 
fragments  that  cluster  together,  the  user 
can  rapidly  identify  themes  of  interest  -  a 


task  that  would  be  tedious  or  impossible  if 
attempting  to  analyze  large  corpora  by 
hand. 

In  her  talk  Ms.  Mehrotra  will  be  addressing 
the  various  technical  challenges  facing  us  in 
building  and  reusing  ontologies  as  well  as 
how  do  tools,  such  as  OSRT  and  IOD,  try  to 
alleviate  some  of  the  problems  in  this  area. 
In  particular  she  will  show  how  Pragati's 
tools  can  help  with  interoperability  issues 
from  diverse  information  sources  such  as 
C2IEDM  (Command  and  Control  Information 
Exchange  Data  Model),  IOM  (IMMACCS 
Object  Model)  and  Cycorp's  Command  Post 
of  Future  knowledge  based  systems. 


Colonel  Robert  C.  Morris,  Jr. 

USJFCOM 

Colonel  Robert  C.  Morris,  Jr.,  is  an  Infantry 
Officer  with  extensive  Special  Operations 
experience.  He  served  in  Korea  as  a 
Mechanized  Platoon  Leader,  Company 
Executive  Officer  and  Scout  Platoon  Leader. 
COL  Morris  served  with  the  2d  Battalion 
(Ranger),  75th  Infantry  in  Fort  Lewis, 
Washington  as  a  rifle  Platoon  Leader, 
Battalion  Support  Platoon  Leader  supporting 
Operation  Urgent  Fury,  and  assistant  S-4. 
He  was  assigned  to  the  4th  Battalion  325th 
Infantry  Airborne  Battalion  Combat  Team 
(Vicenza,  Italy)  as  the  Battalion  S-4  then 
returned  with  the  unit  to  the  82d  Airborne 
Division  as  the  A  Company  Commander 
then  the  Battalion  S-3  (Operations  Officer). 
COL  Morris  then  served  three  years  with  the 
Joint  Special  Operations  Command  at  Pope 
Air  Force  Base,  North  Carolina  as  the 
Logistics  Plans  and  Procurement  Officer 
supporting  special  operations  missions  to 
include  Just  Cause,  Desert  Shield/Desert 
Storm,  and  classified  operations.  He  was 
the  command's  secure  environment 
contracting  officer.  COL  Morris  was  then 
assigned  to  Alaska  as  the  6th  Infantry 
Division  EDRE/Force  Modernization  Officer, 
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G-3  Operations  Officer,  Battalion  Executive 
Officer  for  the  4th  Battalion,  9th  Infantry 
Regiment  MANCHUs,  and  the  1st  Brigade, 
6th  Infantry  Division  (Light)  Executive 
Officer.  During  this  period  COL  Morris  was 
personally  selected  by  the  Principle  Deputy 
to  the  Assistant  Secretary  of  Defense  For 
Special  Operations/Low  Intensity  Conflict 
(SO/LIC)  to  work  at  UN  Headquarters  in 
Geneva  and  design  the  UN  Force  package 
concept.  The  UN  High  Commissioner  for 
Refugees  (Ms  Ogata)  briefed  these, 
unchanged,  to  the  UN  General  Assembly 
where  they  were  approved.  COL  Morris 
then  became  a  special  project  officer  for  the 
ASD  (SO/LIC).  In  this  capacity  he  conduced 
a  multi-service  functional  review  of  the 
humanitarian  excess  program.  His  efforts 
supported  numerous  international 
humanitarian  organizations,  programs,  and 
operations  to  include  Rwanda,  Eritrea,  and 
former  Soviet  republics  to  include 
Kazakhstan  and  Turkmenistan.  COL  Morris 
was  assigned  the  task  to  keep  the 
International  War  Crimes  Tribunal  for 
Rwanda  and  the  former  Yugoslavia  from 
closing  down  in  Rwanda  and  accomplished 
the  task.  COL  Morris  commanded  the  1st 
Battalion,  11th  Infantry  at  Fort  Benning, 
followed  by  service  as  the  Chief,  Forced 
Entry  Battle  Lab.  The  VCSA  and  Cdr, 
JFCOM  created  an  Army  Fellowship  in 
Enroute  Mission  Planning  (EMPRS)  he 
completed  in  lieu  of  the  Army  War  College. 
Following  his  time  in  the  Fort  Benning  Battle 
Lab,  COL  Morris  supported  the  Army's  Unit 
of  Action  Maneuver  Battle  Lab  (UAMBL) 
with  primary  responsibility  to  write  the 
Battle  Command  concept  for  the  Army's 
Future  Force.  He  is  currently  the  Chief  of 
Space  and  Decision  Superiority  for  the 
United  States  Joint  Forces  Command  J9 
(Experimentation)  where  his  primary 
responsibilities  include  developing  and 
experimentally  validating  the  Department  of 
Defense's  future  concepts  for  Information 
Operation,  Adaptive,  Collaborative  Planning 
and  Decision-Making  as  well  as  Global 


Integration  across  the  Inter-Agency 
Community. 

COL  Morris  has  extensive  expertise  in  and 
strong  reputation  with  international 
humanitarian  organizations.  He  authored 
the  Program  of  Instruction  (POI)  for  and  co¬ 
facilitated  the  World  Food  Program's  first 
inter-agency  deliberate  planning  workshop 
in  Burkina  Faso,  Africa.  This  workshop 
marked  the  first  time  a  United  Nations 
Inter-Agency  planning  group  met  with  the 
goal  of  developing  a  strategic  level  plan  to 
react  to  a  complex  emergency,  effectively 
moving  the  organization's  emergency 
response  from  reactive  to  pro-active.  He 
helped  establish  a  program  at  the  Army 
Command  and  General  Staff  College 
(CGSOC)  that  facilitates  collaborative 
planning  exercises  between  military  staffs 
and  Non-governmental  organizations.  He 
has  a  strong  relationship  with  World  Food 
Program,  having  worked  closely  with  its 
current  logistics  director.  COL  Morris 
founded  Partners  International  Foundation, 
a  501(c)(3)  Non-Government  Organization 
(NGO).  The  organization's  goals  is  to  make 
humanitarian  aid  (both  domestically  and 
internationally)  more  efficient  and  cost 
-effective.  Partners  International 
Foundation  is  involved  in  a  myriad  of 
programs  both  in  the  United  States  and 
abroad.  These  include  support  to  local 
community  groups,  women  and  children's 
wellness  in  Rwanda,  a  free  eye-care  clinic  in 
Zimbabwe  and  a  program  to  provide 
international  humanitarian  an  human  rights 
speakers  to  international  military  officers 
studying  in  the  United  States.  Partners 
International  Foundation  recently  sent  an 
assessment  team  of  former  Special  Forces 
Soldiers  to  Tajikistan  and  northern 
Afghanistan  as  well  as  provided  subject 
matter  experts  to  Joint  and  multi-national 
information  operations  experimentation. 
COL  Morris  serves  as  an  officer  in  the 
Foundation  apart  from  his  military  duties 
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and  operates  these  programs  in  his  spare 
time. 

COL  Morris  is  the  author  of  several  articles 
on  military  theory,  humanitarian  operations, 
situational  awareness,  and  international  aid. 

COL  Morris  has  the  Bronze  Star,  the  Legion 
of  Merit,  the  Defense  Meritorious  Service 
Medal,  five  Meritorious  Service  Medals, 
three  Joint  Service  Commendation  Medals, 
the  Army  Commendation  Medal,  the  Joint 
Service  Achievement  Medal,  the  Joint 
Meritorious  Unit  Award,  five  Army 
Achievement  Medals,  Southwest  Asia 
Service  Medal  with  two  bronze  stars,  the 
Armed  Forces  Expeditionary  Medal,  the 
Army  Service  Ribbon,  three  awards  of  the 
Overseas  Ribbon,  the  Southeast  Asia  Kuwait 
Liberation  Medal,  the  Government  of  Kuwait 
Liberation  Medal,  the  National  Defense 
Service  Medal,  the  Expert  Infantryman's 
Badge,  Master  Parachutist  Badge,  and 
Ranger  Tab. 


Dr.  H.  Van  Dyke  Parunak 
Chief  Scientist 
Altarum  Corporation 

Dr.  H.  Van  Dyke  Parunak  ("Van")  is 
Altarum's  Chief  Scientist,  and  a  Corporate 
Analyst  in  the  Emerging  Markets  Group 
within  the  Enterprise  Solutions  Division  at 
Altarum.  He  leads  Altarum's  projects  in 
software  agents,  swarm  intelligence, 
emergent  behavior,  and  nonlinear 
dynamics,  and  has  been  Principal 
Investigator  on  numerous  DARPA  and  other 
projects  involving  these  technologies.  Dr. 
Parunak  is  the  author  or  co-author  of  more 
than  75  technical  articles  and  reports.  He  is 
the  holder  of  two  patents  and  ten  patents 
pending  in  the  area  of  agent  technology. 
His  undergraduate  degree  is  in  Physics  from 
Princeton  University,  and  he  has  five 
graduate  degrees,  including  a  Ph.D.  from 
Harvard  University. 


Dr.  Jens  G.  Pohl 
Executive  Director,  Collaborative 
Agent  Design  Research  Center,  and 
Graduate  Coordinator,  Architecture 
Department,  Cal  Poly,  San  Luis  Obispo, 
California 

Dr.  Jens  Pohl  holds  the  positions  of 
Professor  of  Architecture,  Executive  Director 
of  the  Collaborative  Agent  Design  Research 
Center  (CADRC),  and  Post-Graduate  Studies 
Coordinator,  in  the  College  of  Architecture 
and  Environmental  Design,  California 
Polytechnic  State  University  (Cal  Poly),  San 
Luis  Obispo,  California,  US. 

Professor  Pohl  received  his  formal  education 
in  Australia  with  degrees  in  Architecture  and 
Architectural  Science:  B.Arch.  (University  of 
Melbourne,  1965)  M.Bdg.Sc.  and  Ph.D. 
(University  of  Sydney  1967  and  1970).  He 
taught  in  the  School  of  Building  at  the 
University  of  New  South  Wales  in  Sydney, 
Australia,  until  the  end  of  1972  and  then  left 
for  the  US  where  he  was  appointed  to  the 
position  of  Professor  of  Architecture  at  Cal 
Poly.  Following  several  years  of  research 
and  consulting  activities  in  the  areas  of 
building  support  services  and  information 
systems,  Dr.  Pohl's  research  focus  today  lies 
in  the  application  of  distributed  artificial 
intelligence  methodologies  to  decision- 
support  systems  in  engineering  design, 
logistical  planning,  and  military  command 
and  control. 

Under  his  direction  the  Collaborative  Agent 
Design  Research  Center  at  Cal  Poly  has  over 
the  past  11  years  developed  and 
implemented  a  number  of  distributed 
computing  applications  in  which  multiple 
computer-based  and  human  agents 
collaborate  in  the  solution  of  complex 
problems.  Foremost  among  these  are  the 
ICDM  (Integrated  Cooperative  Decision 
Model)  and  TIRAC  (Toolkit  for  Information 
Representation  and  Agent  Collaboration) 
frameworks  which  have  been  applied  to 
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engineering  design  (industry  sponsorship: 
ICADS  -  1986  to  1991),  energy  conservation 
(US  Dept,  of  Energy  sponsorship:  AEDOT  - 
1992  to  1993),  logistical  planning  (US  Army 
(MTMC)  sponsorship:  ICODES  -  1993  to 
present),  military  mission  planning  (US 
Marine  Corps  (MCWL)  sponsorship:  FEAT, 
FEAT4  and  IMMACCS  -  1994  to  present), 
and  facilities  management  (US  Navy  (ONR) 
sponsorship:  CIAT,  SEAWAY,  and  LOGGY  - 

1996  to  present). 

The  Integrated  Marine  Multi-Agent 
Command  and  Control  System  (IMMACCS) 
was  successfully  field-tested  as  the 
command  and  control  system  of  record 
during  the  Urban  Warrior  Advanced 
Warfighting  Exercise  (AWE)  conducted  by 
the  Marine  Corps  Warfighting  Laboratory 
(MCWL)  in  Central  California  (Monterey  and 
Oakland)  during  the  period  March  11  to  18, 
1999,  during  a  live  fire  Limited  Objectives 
Exercise  (LOE)  held  at  Twentynine  Palms, 
California,  in  March  2000,  and  during  the 
recent  Kernal  Blitz  Exercise  held  on  the 
West  Coast  in  June  2001.  The  Integrated 
Computerized  Deployment  System 
(ICODES)  was  designated  by  the  US 
Department  of  Defense  as  the  'migration 
system'  for  ship  loading  in  July  1995. 
ICODES  V.3  was  released  to  the  US  Army  in 

1997  and  ICODES  V.5  is  being  released  to 
the  US  Marine  Corps  and  US  Navy  this  year 
(2002). 

Dr.  Pohl  is  the  author  of  two  patents  (US), 
several  books,  and  more  than  80  research 
papers.  He  is  a  Fellow  of  the  International 
Institute  for  Advanced  Studies  in  Systems 
Research  and  Cybernetics,  and  was 
awarded  on  honorary  doctorate  by  the 
Institute  in  August,  1998,  during  the 
InterSymp-98  conference  held  in  Baden- 
Baden,  Germany.  Professor  Pohl  is  a  Fellow 
of  the  Royal  Australian  Institute  of 
Architects,  a  Fellow  of  the  Australian 
Institute  of  Building,  a  Member  of  the 


American  Institute  of  Constructors,  and  a 
member  of  IEEE. 


Dr.  Conrad  W.  Strack 

Senior  Systems  Analyst,  CSCI 

Conrad  W.  Strack,  Ph.D.  Senior  Systems 
Analyst  at  CSCI,  responsible  for  developing 
quantitative  estimates  of  cost,  performance, 
and  benefits  for  the  definition,  design,  and 
evaluation  of  military  and  intelligence 
systems. 

Specific  experience  includes: 

•  network-centric  interoperability 
costs  Estimated  life-cycle  costs  of 
achieving  interoperability  for  a  layered 
family  of  defense  platforms  using  JDN 
(Link  16),  CEC,  and/or  JCTN  for  legacy 
software,  open  architecture,  or  common 
host  versions  of  Aegis,  LH,  CV,  E-2C, 
TPS-59,  AWACS,  Patriot,  THAAD,  JLENS, 
MEADS,  Sentinel,  JSTARS,  Predator, 
Global  Hawk,  SBIRS,  TPS-75  with  EMT, 
F-16  block  50,  F-18  E/F,  JSF,  F-22,  Navy 
Area,  and  Navy  Theaterwide. 

•  network-centric  C3  effectiveness 

Designed  and  directed  Joint  Service 
experiments  at  the  Naval  Postgraduate 
School  to  estimate  value  added  by  C3 
network  attributes  -  connectivity, 
centrality,  organization,  and  coordination 
-  to  military  force  effectiveness. 

•  C3  performance  evaluation  Directed 
support  of  JCS  C3  Global  Assessment, 
producing  the  JCS  C3  Master  Plan, 
USSOUTHCOM  C3  Master  Plan ,  JCS  C3 
Architecture  Annex,  USTRANSCOM  PAR 
Annex,  and  the  USSPACECOM  PAR 
Annex. 

•  interoperability  countermeasures 

Devised  the  first  complete  system-level 
defense  suppression  attacks  and  BM/C3 
countermeasures  for  Brilliant  Pebbles  and 
Ground  Based  Interceptor  layered 
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defense  architectures.  This  included 
target  selection,  launch  and  penetration 
strategies,  and  integrated 
countermeasures  suites. 

•  specific  interoperability  cost 
estimates 

CEC,  JCTN,  Gateway,  Minimum  Mix, 
MMAA,  National  Cruise  Missile 
Defense,  TBMD  Using  Link  16,  JTAMD 
Master  Plan,  JMAA,  JTAMD  EXCOM, 
JDEP,  RAMOS,  NATO  TAMD,  SIAP 
Block  1,  BMDSAS,  Common  Host 
Initiative. 


Dr.  Andreas  Tolk 
Virginia  Modeling  Analysis  and 
Simulation  Center,  Old  Dominion 
University 

Dr.  Andreas  Tolk  is  Senior  Research 
Scientist  at  the  Virginia  Modeling  Analysis 
and  Simulation  Center  (VMASC)  of  the  Old 
Dominion  University  (ODU)  of  Norfolk, 
Virginia.  He  has  over  14  years  of 
international  experience  in  the  field  of 
Applied  Military  Operations  Research  and 
Modeling  and  Simulation  of  and  for 
Command  and  Control  Systems.  He 
participated  in  several  projects  of  the  NATO 
Research  &  Technology  Organization  as  a 
subject  matter  expert  for  M&S  and 
Command  and  Control.  In  addition  to  his 
research  work,  he  gives  lectures  in  the  M&S 
program  of  ODU.  His  domain  of  expertise  is 
the  integration  of  M&S  functionality  into 
related  application  domains,  such  as  C4ISR 
or  Service-oriented  Architectures,  in 
particular  based  on  open  standards. 


Mr.  Peter  M.  Trask 

The  Johns  Hopkins  University,  Applied 
Physics  Laboratory 

Peter  M.  Trask  is  the  Branch  Supervisor  for 
Strategic  and  National  Command  and  Control 
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at  The  Johns  Hopkins  University,  Applied 
Physics  Laboratory  (JHU/APL),  in  Laurel, 
Maryland.  He  is  responsible  for  JHU/APL 
programs  in  global  information  integration 
and  decision-making,  focusing  on  the  DoD's 
transition  to  net-centric  operations  and 
warfare. 

From  1997  through  March  2004,  Mr.  Trask 
was  a  member  of  the  federal  government's 
Senior  Executive  Service  (SES).  He  served  as 
Product  Area  Director  for  Undersea  Warfare 
(USW)  Weapons  and  Vehicle  Systems  at  the 
Naval  Undersea  Warfare  Center  (NUWC)  in 
Newport,  Rhode  Island.  He  was  responsible 
for  programs  across  the  Naval  Sea  Systems 
Command  (NAVSEA)  warfare  centers  in 
torpedoes,  unmanned  undersea  vehicles, 
platform  defensive  systems,  USW  launchers, 
submarine  tactical  missile  systems 
integration,  and  USW  unmanned  surface 
vehicles.  Prior  to  that,  he  was  Head  of  the 
Submarine  Electromagnetic  Systems 
Department,  where  he  had  responsibility  for 
NUWC's  work  in  submarine  communications, 
electronic  surveillance,  information 
operations,  and  imaging  systems  and  served 
as  lead  for  NUWC's  FORCEnet  initiatives.  He 
was  a  member  of  the  Navy's  acquisition 
professional  community  and  was  NAVSEA's 
technical  authority  warrant  holder  for 
submarine  imaging  and  electronic  warfare 
systems. 

From  1995  to  1997,  Mr.  Trask  was  a  member 
of  the  senior  professional  staff  at  JHU/APL, 
where  he  was  responsible  for  development 
and  transition  of  submarine  information 
management  and  communications  programs. 
From  1987  to  1989,  he  served  as  Science 
Advisor  to  the  Commander,  Submarine  Force, 
U.S.  Atlantic  Fleet  in  Norfolk,  Virginia,  where 
he  was  responsible  for  introducing  several 
quick-reaction  capabilities  for  submarines  in 
response  to  urgent  operational  requirements. 
Early  in  his  career,  Mr.  Trask  performed 
RDT&E  of  submarine  communications 
antennas  and  submarine  ESM  systems  at 


NUWC's  Detachment  in  New  London, 
Connecticut.  He  later  served  in  several 
management  positions  at  NUWC,  including 
program  manager  for  Submarine  Electronic 
Warfare  Systems  and  Periscopes,  and  Head  of 
the  Communications  Systems  Division. 

Mr.  Trask  received  a  Bachelor  of  Science 
degree  in  electrical  engineering  in  1971  from 
Northeastern  University  where  he  was  elected 
to  the  Tau  Beta  Pi  and  Eta  Kappa  Nu 
engineering  honor  societies.  In  1976,  he 
received  a  Master  of  Science  degree  in 
electrical  engineering  from  the  University  of 
Connecticut.  In  1984,  he  was  selected  as  a 
Fellow  at  the  Sloan  School  of  Management  at 
the  Massachusetts  Institute  of  Technology, 
where  he  received  a  Master  of  Science  degree 
in  management  in  1985.  He  has  received  the 
National  Defense  Industrial  Association 
Bronze  Medal,  Navy  Superior  Civilian  Service 
Award,  and  the  Navy's  Science  Advisor  of  the 
Year  award.  He  has  been  a  lecturer  in  the 
MIT  Professional  Summer  Program  and  has 
presented  at  numerous  professional 
conferences. 


Mr.  Paul  Ulrich 

Shonborn  Becker  Systems,  Inc. 

Mr.  Paul  Ulrich  is  a  Senior  Technical  Advisor 
to  the  Project  Manager  Ground  Combat 
Command  &  Control  (PM  GCC2)  and  the 
Product  Manager  for  the  Army's  Maneuver 
Control  System  (PM  MCS),  where  he  works  on 
a  wide  range  of  advanced  concepts.  He 
serves  as  the  US  Head  of  Delegation  to  the 
Multilateral  Interoperability  Programme  (MIP), 
a  multinational  interoperability  effort  to 
specify  how  to  exchange  data  between  C2 
Information  Systems  in  a  coalition 
environment.  He  has  served  as  the  Chairman 
of  the  MIP  Steering  Group  (MSG)  as  well  as 
Chairman  of  the  MIP  Programme 
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As  the  principal  author  of  the  US  Navy  and 
Marine  Corps  "Maritime  Prepositioning 

Concept",  he  developed  a  detailed  concept 
and  then  supervised  the  implementation  of 
a  national  strategic  response  capability 
based  on  forward  positioning  three 

squadrons  of  specially  configured  climate 
controlled  ships.  Each  of  these  squadrons 
contained  prepackaged  supplies  and 
equipment  sufficient  to  support  a  force  of 
15,000  Marines  for  thirty  days.  While 

serving  as  Chief  of  Staff  Marine  Forces 

Pacific,  Colonel  Wood  was  dispatched  to 
Russia  in  1993.  There,  over  a  two-week 
period  of  negotiations,  he  successfully 
concluded  a  major  tension  reduction 
agreement  and  multi-year  exercise  program 
with  the  Russian  General  Staff,  the 
Commander  Russian  Pacific  Fleet  in 
Vladivostok,  and  the  Commander  Russian 
Far  East  Military  District  in  Kharbovsk. 
Designed  to  relax  tensions  and  reduce  the 
risk  of  nuclear  incidents  in  the  Pacific 
Theater,  the  agreement  has  since  been 
extended. 

Colonel  Wood's  last  billet  was  as  founding 
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approach  as  well  as  its  projection  of  a  very 
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In  my  introduction  to  this  year’s  conference  I  will  address  six  questions  that  I  believe 
come  to  the  core  of  our  conference  theme  of  interoperability.  Do  we  human  beings  resist 
change?  Is  it  in  fact  a  human  problem  and  not  a  technical  problem  that  we  are  dealing 
with?  Can  non-human  intelligence  exist?  Do  we  even  have  a  need  for  intelligent 
software?  How  did  software,  particularly  intelligent  software  (i.e.,  if  we  accept  that  there 
is  such  a  thing)  evolve  over  the  past  several  decades,  and  what  is  all  this  talk  about  a 
Semantic  Web  environment?  And,  finally,  what  does  the  future  hold  in  the  next  five  to 
ten  years? 


We  are  driven  to  advances  in  information 
technology  by  sinister  forces. 

Wm\  — 

We  find  ourself  suddenly  at  war... 

...facing  unpredictable  enemies... 

m.  ...facing  insecurity  everywhere... 

...facing  revolutionary  changes. 

U  Our  freedom  is  being  threatened. 

Period  of  accelerated  change! 

A  very  unsettling  time  in  human  history. 


Fig.2:  .  .it  was  the  worst  of  times. . .” 

I  would  like  to  start  by  paraphrasing  one  of  my  favorite  authors,  Charles  Dickens.  Many 
of  you  will  recall  that  in  The  Tale  of  Two  Cities,  he  started  off  the  entire  book  with  a  long 
paragraph  that  began  with  the  words:  "...it  was  the  best  of  times,  it  was  the  worst  of 
times..."  These  are  words  that  I  believe  apply  very  much  today.  We  are  in  the  best  of 
times,  because  information  technology  and  computers  have  become  a  useful  partner  and 
enabler  that  bring  us  very  powerful  capabilities.  To  mention  only  a  few  (Fig.  1),  we  have: 
global  connectivity;  very  fast  data  storage  and  processing  devices;  powerful  analysis  and 
problem  solving  assistance;  tireless  monitoring  and  warning  facilities;  and,  intelligent 
information  management  services.  All  of  these  capabilities  greatly  enable  the  individual. 
Today  a  single  person  is  able  to  accomplish  what  entire  organizations  had  difficulty 


Information  technology  and  computers 
have  become  our  useful  partner 
and  enabler. 

• 

Instant  global  connectivity. 

• 

Fast  data  storage  and  processing. 

• 

Powerful  analysis  and  problem 
solving  assistance. 

• 

Tireless  monitoring  and  warning 
facilities. 

• 

Intelligent  information  management 
services. 

Enablement  of  the  individual! 

A  very  exciting  time  in  human  history. 


Fig.l:  “...it  was  the  best  of  times...” 
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accomplishing  20  to  30  years  ago.  Surely,  all  of  this  adds  up  to  a  very  exciting  time  in 
human  history. 

But  surely,  we  are  also  experiencing  the  worst  of  times  (Fig. 2).  We  are  driven  to 
information  system  advances  by  very  sinister  forces.  Suddenly,  we  find  ourselves  at  war, 
facing  unpredictable  enemies,  insecurity  everywhere,  and  revolutionary  change.  Our  very 
freedom  is  being  threatened.  We  are  in  a  period  of  accelerated  change  and  such  periods 
bring  about  a  great  deal  of  tension.  Therefore,  we  are  also  experiencing  a  very  unsettling 
time  in  human  history.  What  are  some  of  these  changes,  and  they  are  indeed  profound 
changes.  We  are  transitioning  from  a  society  that  was  largely  governed  by  a  sense  of 
singularity  to  a  society  that  has  to  increasingly  deal  with  plurality.  Most  everything  that 
we  human  beings  have  designed  and  produced  in  the  past  has  been  mechanical  in  nature. 
Mechanical  systems  are  sequential  systems.  Organic  systems,  information  systems,  are 
pluralistic  systems.  They  operate  in  parallel.  So  we  are  moving  from  a  world  that  used 
to  be  paced  by  sequential  actions  to  a  world  in  which  a  great  deal  of  parallelism  exists. 

Human  Resistance  to  Change 

We  used  to  learn  that  the  most  efficient  way  of  providing  services  is  to  centralize  those 
services.  Today  we  know  that  centralized  facilities  are  a  serious  liability,  because  they 
present  a  tempting  and  relatively  convenient  target  to  terrorist.  It  has  become  generally 
acknowledged  that  we  need  to  distribute  our  essential  facilities  and  services  in  a 
networked  manner  with  a  high  degree  of  redundancy.  We  are  learning  to  move  from  a 
hierarchical  organizational  structure  in  management  to  a  very  flat  organizational 
structure.  This  change  in  management  philosophy  and  style  is  further  evidence  of  the 
enablement  of  the  individual.  Organizations  are  becoming  increasingly  interested  in 
knowledge  management,  as  they  begin  to  realize  the  value  of  every  person  in  the 
organization.  Particularly,  our  military  forces  are  moving  from  a  centralized  command 
and  control  environment  to  distributed  command  and  coordination  with  power  at  the 
edge. 

There  is  another  change  that  is  much  more  subtle,  yet  very  important.  Over  the  past 
century  mathematicians  have  made  great  strides  in  providing  us  with  powerful  tools  for 
categorizing,  analyzing  and  identifying  patterns  in  large  sets  of  data.  I  am  referring  to  the 
field  of  statistics,  which  is  largely  based  on  norms  (i.e.,  on  satisfying  the  majority  of  any 
data  set  or  population).  Means,  standard  deviations  and  confidence  limits,  regardless  of 
how  accurately  we  can  calculate  them  mathematically,  do  not  give  us  much  protection 
from  asymmetric  threats.  Today,  the  exceptions  are  becoming  more  and  more  important. 
That  is  a  major  paradigm  shift.  We  can  no  longer  consider  the  norms  alone,  but  must 
increasingly  look  at  the  exceptions.  Yet,  we  have  few  if  any  tools  to  help  us  with  the 
assessment  of  exceptions.  Whether  a  person  is  going  to  become  a  suicide  bomber  is  not 
something  that  you  are  going  to  be  able  to  predict  statistically.  The  factors  governing 
such  behavior  tend  to  be  governed  by  exceptional  circumstances. 

We  human  beings  have  an  innate  aversion  to  change.  Why  is  this  so?  The  reason  is  that 
we  are  in  every  respect  experience-based.  Our  confidence  or  comfort  level  comes  from 
our  experience.  As  soon  as  we  move  out  of  our  experience  base  we  move  into  the 
unknown  and  we  move  into  a  risk  area.  Physiologically,  we  are  a  product  of  biological 
evolution.  Our  brain  is  composed  of  different  parts,  some  of  which  are  deeply  rooted  in 
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the  evolution  of  our  earliest  ancestors.  We  adapt  continuously  and  gain  in  experience  as 
we  react  to  the  stimulation  of  our  environment.  Psychologically,  we  are  subject  to  often 
uncontrolled  emotional  forces.  Our  confidence  is  fragile.  We  are  fearful  of  the  unknown 
and  intellectually,  as  I  mentioned  previously,  we  are  almost  entirely  experience-based. 
We  rely  heavily  upon  intuition  and  our  forecasts  of  the  future  are  usually  wrong. 

|  Western  Union  Executive  - 1876:  | 

"The  telephone  has  too  many  shortcomings  to  be  seriously 
considered  as  a  means  of  communication." 

|  Lord  Kelvin  -  1895:  | 

"Heavier-than-air  flying  machines  are  not  possible." 

I  Thomas  Watson.  IBM  Chairman  -  1943~| 

"I  think  there  is  a  world  market  for  maybe  five  computers." 

|  John  von  Neumann  -  1949:  | 

"It  would  appear  that  we  have  reached  the  limits  of  what  is 
possible  to  achieve  with  computer  technology,  although  one 
should  be  careful  with  such  statements,  as  they  tend  to  sound 
pretty  silly  in  five  years." 

|  Ken  Olson  -  1977:  | 

"There  is  no  reason  for  individuals  to  have  a  computer  in 
their  home." 

|  Bill  Gates -1981:  | 

“640,000  bytes  of  memory  ought  to  be  enough  for  anybody". 

|  Robert  Metcalfe  (inventor  of  the  Ethernet):  | 

"The  Internet  will  catastrophically  collapse  in  1996." 


Fig.3:  Forecasting  the  future 

The  fact  is  that  we  are  involved  in  changes  that  constitute  a  paradigm  shift  and  are  the 
cause  of  a  great  deal  of  tension.  In  talking  about  forecasting  the  future,  not  long  ago  in 
1943  (Fig.3),  we  had  the  Chairman  of  IBM  Corporation,  Thomas  Watson,  saying:  "...I 
think  there  is  a  world  market  for  maybe  five  computers."  In  1949,  John  van  Neumann 
said  with  a  little  less  certainty:  “...It  would  appear  that  we  have  reached  the  limits  with 
what  it  is  possible  to  achieve  with  computer  technology,  although  one  should  be  careful 
with  such  statements  as  they  tend  to  sound  pretty  silly  in  five  years."  Ken  Olson,  in  1977 
prophesized:  “. .  .There  is  no  reason  for  individuals  to  have  a  computer  in  their  home."  In 
1981,  Bill  Gates  suggested  that:  “...640K  bytes  of  memory  ought  to  be  enough  for 
anybody."  And  finally,  Robert  Metcalf  the  inventor  of  the  Ethernet  warned  us  that: 
“...The  Internet  will  catastrophically  collapse  in  1996."  So,  we  don’t  do  well  looking 
into  the  future  for  the  simple  reason  that  we  have  no  experience  to  base  that  future  on. 

In  terms  of  human  cognition  and  intuition  (Fig.4),  the  reality  is  that  we  often  see  patterns 
where  there  are  none.  The  greater  the  complexity  the  more  misleading  our  intuition  tends 
to  be.  More  often  than  not  we  are  biased  in  favor  of  the  status  quo,  because  that  is  our 
experience  and  we  tend  to  judge  new  circumstances  based  on  past  conditions. 

Human  and  Non-Human  Intelligence 

Can  there  be  non-human  intelligence?  Can  the  computer  help  us  in  our  decision  making 
endeavors  in  an  intelligent  partnership  role?  The  answer  to  this  question  depends  very 
much  on  our  viewpoint  or  premises.  Human  beings  tend  to  be  rather  self-centered.  We 
believe  that  everything  in  our  environment  revolves  around  us.  Therefore,  from  our 


We  often  see  patterns  where  there 
are  none. 


The  greater  the  complexity  the  more 
misleading  intuition  can  be. 


We  tend  to  be  biased  in  favor  of 
status  quo. 


We  tend  to  judge  new  circumstances 
based  on  past  conditions. 


Fig.4:  The  frailties  of  human  intuition 
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human  point  of  view,  we  are  easily  persuaded  that  intelligence  is  something  that  belongs 
innately  to  us.  This  school  of  thought  argues  that  computers  are  electronic  machines  that 
do  not  and  will  never  display  truly  intelligent  capabilities  (Fig. 5).  Certainly,  I  would 
agree  that  computers  are  unlikely  to  gain  human  intelligence  in  the  near  future.  Several 
strong  arguments  are  advance  by  that  school  (Dreyfuss  1979  and  1997,  Dreyfuss  and 
Dreyfuss  1986,  Lucas  1961,  Searle  1980  and  1992).  First,  it  is  argued  that  humans  are 
situated  in  the  world  by  virtue  of  their  bodies  and  that  human  level  intelligence  is 
impossible  without  a  body.  The  second  argument  points  out  that  symbolic  reasoning  and 
logic  are  not  the  basis  of  human  intelligence.  Human  behavior  is  not  rational  and 
thinking  does  not  necessarily  follow  rules.  Third,  it  is  argued  that  the  world  can  be 
neither  analyzed  nor  divided  into  independent  logical  elements.  It  therefore  follows  that 
the  formalization  and  simulation  of  intelligent  behavior  is  not  possible.  The  final 
summary  argument  of  that  school  of  thought  is  that  for  these  stated  reasons  intelligence  is 
the  province  of  living  creatures,  specifically  human  beings. 


Computers  are  electronic  machines  that  do  not  and 
will  never  display  truly  intelligent  capabilities. 


Arguments: 


Humans  are  'situated'  in  the  world  (i.e.,  in  a 
problem  situation)  by  virtue  of  their  bodies. 
Human-level  intelligence  is  impossible 
without  a  body. 


Symbolic  reasoning  is  not  the  basis  of  human 
intelligence.  Human  behavior  is  not  rational 
and  thinking  does  not  necessarily  follow  rules. 


The  world  cannot  be  analyzed  (i.e..  divided) 
into  independent  logical  elements.  Therefore, 
the  formalization  and  simulation  of  intelligent 
behavior  is  not  possible. 


Intelligence  is  the  province  of  living  creatures , 
specifically  human  beings. 


Humans  are  self-centered  and  erroneous  in  their 
view  that  'human  intelligence'  and  'intelligence' 
are  synonymous. 

Arguments: 


Fundamental  elements  of  'intelligence' 
include  the  ability  to  remember,  reason, 
team,  and  discover. 


•  Remembering  is  the  lowest  level  of  intelligence' 
and  computers  are  well  capable  of  storing 
massive  amounts  of  data. 


•  Reasoning  is  a  higher  level  of  'intelligence'  and 
computers  are  capable  of  reasoning  about  data 
if  provided  with  context. 


•  Computers  have  been  known  to  have  leaming- 
like  capabilities. 

•  Computers  can  discover  information  through 
assodations  and  pattern  matching. 


Human  intelligence  and  computer-based  intelligence 
can  be  applied  to  complement  each  other. 


Fig.5:  The  human  view  of  intelligence 


Fig.6:  A  general  view  of  intelligence 


A  more  general  view  of  intelligence  would  hold  that  there  are  some  fundamental 
elements  of  intelligence  such  as  the  ability  to  remember,  to  reason,  to  learn,  and  to 
discover  or  create  (Fig.6).  From  that  point  of  view,  remembering  as  the  lowest  level  of 
intelligence  can  certainly  be  accomplished  by  computers.  In  fact,  one  could  argue  that 
that  the  storage  capacity  of  computers  exceeds  the  long  term  memory  capacity  of  human 
beings.  Reasoning  is  a  higher  level  of  intelligence  and  computers  are  capable  of 
reasoning  as  long  as  they  have  some  context  within  which  to  reason.  Computers  cannot 
reason  about  data  without  context.  I  will  come  back  to  that  issue  in  a  few  minutes.  Also, 
computers  have  been  shown  to  have  some  learning  capabilities,  and  computers  can  even 
discover  information  through  association  and  pattern  matching.  The  concept  of  discovery 
is  a  core  capability  on  which  many  of  the  expected  capabilities  of  the  Global  Information 
Grid  (GIG)  will  depend.  That  is,  the  notion  that  a  software  application  will  be  able  to 
automatically  discover  resources. 
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The  Need  for  Intelligent  Software 

Whether  there  is  a  need  for  intelligent  software,  is  the  next  obvious  question?  Until  about 
four  years  ago,  whenever  I  made  a  presentation  like  this  there  would  always  be  a  number 
of  people  who  would  come  to  me  afterwards  and  say:  “...well  this  all  sounds  very 
feasible,  but  do  we  need  computer  intelligence?  Surely,  we  human  beings  are  the  ones 
who  have  intelligence  and  we  will  be  able  to  do  the  necessary  reasoning  and 
interpretation  of  data.”  Today,  I  rarely  hear  those  arguments,  because  we  are  beginning 
to  realize  that  we  are  inundated  with  data,  and  we  desperately  need  help. 

There  are  essentially  two  compelling  reasons  why  computer  software  must  increasingly 
incorporate  more  and  more  ‘intelligent’  capabilities.  The  first  reason  relates  to  the  current 
data-processing  bottleneck.  Advancements  in  computer  technology  over  the  past  several 
decades  have  made  it  possible  to  store  vast  amounts  of  data  in  electronic  form.  Based  on 
past  manual  information  handling  practices  and  implicit  acceptance  of  the  principle  that 
the  interpretation  of  data  into  information  and  knowledge  is  the  responsibility  of  the 
human  operators  of  the  computer-based  data  storage  devices,  emphasis  was  placed  on 
storage  efficiency  rather  than  processing  effectiveness.  Typically,  data  file  and  database 
management  methodologies  focused  on  the  storage,  retrieval  and  manipulation  of  data 
transactions,  rather  than  the  context  within  which  the  collected  data  would  later  become 
useful  in  planning,  monitoring,  assessment,  and  decision-making  tasks. 

The  second  reason  is  somewhat  different  in  nature.  It  relates  to  the  complexity  of 
networked  computer  and  communication  systems,  and  the  increased  reliance  of 
organizations  on  the  reliability  of  such  information  technology  environments  as  the  key 
enabler  of  their  effectiveness,  profitability  and  continued  existence. 

The  Data-Processing  Bottleneck 

This  requires  further  explanation,  as  a  fundamental  issue  and  one  of  the  primary 
forces  driving  the  evolution  of  software  intelligence.  The  design  of  any 
information  system  architecture  must  be  based  on  the  obvious  truth  that  the  only 
meaningful  reason  for  capturing  and  storing  data  is  to  utilize  them  in  some 
planning  or  decision-making  process.  However  for  data  to  be  useful  for  planners 
and  decision  makers  they  have  to  be  understood  in  context.  In  other  words,  data 
are  just  numbers  and  words  that  become  meaningful  only  when  they  are  viewed 
within  a  situational  framework.  This  framework  is  typically  defined  by 
associations  that  relate  data  items  to  each  other  and  peripheral  factors,  which 
influence  the  meaning  of  the  data  in  a  particular  situation.  Succinctly  stated, 
numbers  and  words  (i.e.,  data)  found  within  a  rich  set  of  relationships  become 
information,  which  provides  the  necessary  context  for  interpreting  the  meaning  of 
the  data,  the  recognition  of  patterns,  and  the  formulation  of  rules,  commonly 
referred  to  as  knowledge. 

The  larger  an  organization  the  more  data  it  generates  itself  and  captures  from 
external  sources.  With  the  availability  of  powerful  computer  hardware  and 
database  management  systems  the  ability  of  organizations  to  store  and  order  these 
data  in  some  purposeful  manner  has  dramatically  increased.  However,  at  the 
same  time,  the  expectations  and  need  to  utilize  the  stored  data  in  monitoring, 
planning  and  time-critical  decision-making  tasks  has  become  a  major  human 
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resource  intensive  preoccupation.  In  many  respects  this  data-centric  focus  has 
become  a  bottleneck  that  inhibits  the  ability  of  the  organization  to  efficiently  and 
effectively  accomplish  its  mission. 


LOW  VOLUME 


Automatic  Absorption  of  Data  as  Information 
Through  Human  Held  Context 


Knowledge] 


Fig.7:  From  data  to  knowledge 


Fig.  8:  Human  interpretation  of  data 


The  reasons  for  this  bottleneck  are  twofold.  First,  large  organizations  are  forced 
to  focus  their  attention  and  efforts  on  the  almost  overwhelming  tasks  involved  in 
converting  unordered  data  into  purposefully  ordered  data  (Fig.7).  This  involves, 
in  particular,  the  establishment  of  gateways  to  a  large  number  of  heterogeneous 
data  sources,  the  validation  and  integration  of  these  sources,  the  standardization  of 
nomenclatures,  and  the  collection  of  data  elements  into  logical  data  models. 
Second,  with  the  almost  exclusive  emphasis  on  the  slicing  and  dicing  of  data, 
rather  than  the  capture  and  preservation  of  relationships,  the  interpretation  of  the 
massive  and  continuously  increasing  volume  of  data  is  left  to  the  users  of  the  data 
(Fig.8).  The  experience  and  knowledge  stored  in  the  human  cognitive  system 
serves  as  the  necessary  context  for  the  interpretation  and  utilization  of  the  ordered 
data  in  monitoring,  planning  and  decision-making  processes.  However,  the  burden 
imposed  on  the  human  user  of  having  to  interpret  large  amounts  of  data  at  the 
lowest  levels  of  context  has  resulted  in  a  wasteful  and  often  ineffective 
application  of  valuable  and  scarce  human  resources.  In  particular,  it  often  leads  to 
late  or  non-recognition  of  patterns,  overlooked  consequences,  missed 
opportunities,  incomplete  and  inaccurate  assessments,  inability  to  respond  in  a 
timely  manner,  marginal  decisions,  and  unnecessary  human  burn-out.  These  are 
symptoms  of  an  incomplete  information  management  environment.  An 
environment  that  relies  entirely  on  the  capture  of  data  and  the  ability  of  its  human 
users  to  add  the  relationships  to  convert  the  data  into  information  and  thereby 
provide  the  context  that  is  required  for  all  effective  planning  and  decision-making 
endeavors. 
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A  more  complete  information  management  environment  considers  data  to  be  the 
bottom  layer  of  a  three-layer  architecture,  namely: 

A  Data  Layer  that  integrates  heterogeneous  data  sources  into  accessible 
and  purposefully  ordered  data.  It  typically  includes  a  wide  variety  of 
repositories  ranging  from  simple  textual  files  to  databases,  Data  Portals, 
Data  Warehouses,  and  Data  Marts. 

A  Mediation  Layer  that  defines  the  structure  of  the  data  sources  (i.e., 
logical  data  models),  data  transfer  formats,  and  data  transformation  rules. 

The  two  principal  purposes  of  the  Mediation  Layer  are  to  facilitate  the 
automated  discovery  of  data  and  to  support  the  mapping  of  data  to 
information.  In  other  words,  the  Mediation  Layer  serves  as  a  registry  for 
all  definitions,  schemas,  protocols,  conventions,  and  rules  that  are  required 
to  recognize  data  within  the  appropriate  context.  The  Mediation  Layer  also 
serves  as  a  translation  facility  for  bridging  between  data  with  structural 
relationships  (e.g.,  based  on  a  logical  data  model)  and  information  that  is 
rich  in  contextual  relationships. 

An  Information  Layer  that  consists  of  many  functionally  oriented 
planning  and  decision-assistance  software  applications.  Typically,  these 
applications  are  based  on  internal  information  models  (i.e.,  object  models 
or  ontologies)  that  are  virtual  representations  of  particular  portions  of  the 
real  world  context.  By  providing  context,  the  internal  information  model 
of  each  application  is  able  to  support  the  automated  reasoning  capabilities 
of  rule-based  software  agents. 

In  such  a  three-layered  information  management  environment  the  Mediation 
Layer  continuously  populates  the  information  models  of  the  applications  in  the 
Information  Layer  with  the  data  changes  that  are  fed  to  it  by  the  Data  Layer.  This 
in  turn  automatically  triggers  the  reasoning  capabilities  of  the  software  agents. 
The  collaboration  of  these  agents  with  each  other  and  the  human  users  contributes 
a  powerful,  near  real-time,  adaptive  decision-support  environment.  The  agents 
can  be  looked  upon  as  intelligent,  dynamic  tools  that  continuously  monitor 
changes  in  the  real  world.  They  utilize  their  reasoning  and  computational 
capabilities  to  generate  and  evaluate  courses  of  action  in  response  to  both  real 
world  events  and  user  interactions.  As  a  result  the  human  user  is  relieved  of  many 
of  the  lower  level  filtering,  analysis,  and  reasoning  tasks  that  are  a  necessary  part 
of  any  useful  planning  and  problem  solving  process.  However,  just  as 
importantly,  the  software  agents  continuously  and  tirelessly  monitor  the  real 
world  execution  environment  for  changes  and  events  that  may  impact  current  or 
projected  plans. 

The  Increasing  Complexity  of  Information  Systems 

The  economic  impact  on  an  organization  that  is  required  to  manually  coordinate 
and  maintain  hundreds  of  interfaces  between  data-processing  systems  and 
applications  that  have  no  ‘understanding’  of  the  data  that  they  are  required  to 
exchange,  is  enormous.  Ensuing  costs  are  not  only  related  to  the  requirement  for 
human  resources  and  technical  maintenance  (normally  contracted  services),  but 
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also  to  the  indirect  consequences  of  an  information  systems  environment  that  has 
hundreds  of  potential  failure  points. 


Recent  studies  conducted  by  IBM  Corporation  and  others  have  highlighted  the 
need  for  autonomic  computing  as  the  organizational  expectations  and  dependence 
on  information  services  leads  to  more  and  more  complex  networked  computer 
solutions  (Ganek  and  Corbi  2003).  In  the  commercial  sector  “...it  is  now 
estimated  that  at  least  one-third  of  an  organization’s  IT  (Information  Technology) 
budget  is  spent  on  preventing  or  recovering  from  crashes”  (Patterson  et  al.  2002). 
Simply  stated  (Fig. 9),  autonomic  computing  utilizes  the  ‘understanding’  that  can 
be  represented  within  an  information-centric  software  environment  to  allow 
systems  to  automatically:  (1)  reconfigure  themselves  under  dynamically  changing 
conditions;  (2)  discover,  diagnose,  and  react  to  disruptions;  (3)  maximize  resource 
utilization  to  meet  end-user  needs  and  system  loads;  and,  (4)  anticipate,  detect, 
identify,  and  protect  themselves  from  external  and  internal  attacks. 


|  Ability  to  adapt  to  dynamically 

I  changing  environments  (e.g.,  plug 
and  play  devices,  addition  of  new 
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Fig.9:  Desirable  autonomic  capabilities  Fig.  10:  Autonomic  self-healing  facilities 


These  same  studies  have  found  that  more  than  40%  of  computer  system 
disruptions  and  failures  are  due  to  human  error.  However,  the  root  cause  of  these 
human  errors  was  not  found  to  be  lack  of  training,  but  system  complexity.  When 
we  consider  that  computer  ‘downtime’  due  to  security  breaches  and  recovery 
actions  can  cost  as  much  as  (US)$2  million  per  hour  for  banks  and  brokerage 
firms,  the  need  for  computer-based  systems  that  are  capable  of  controlling 
themselves  (i.e.,  have  autonomic  capabilities)  assumes  critical  importance. 

A  core  requirement  of  autonomic  computing  is  the  ability  of  a  computer-based 
information  system  to  recover  from  conditions  that  already  have  caused  or  will 
likely  cause  some  part(s)  of  the  system  to  fail.  As  shown  in  Fig.  10,  this  kind  of 
self-healing  capability  requires  a  system  to  continuously  monitor  itself  so  that  it 
can  identify,  analyze  and  take  mitigating  actions,  preferably  before  the  disruption 
takes  place.  In  addition,  the  system  should  be  able  to  learn  from  its  own 
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experience  by  maintaining  a  knowledge  base  of  past  conditions  that  have  caused 
malfunctions  and  the  corrective  measures  that  were  taken. 

In  summary,  the  continued  expansion  of  networks  (e.g.,  the  Internet  and  its  successors) 
will  provide  seamless  connectivity  among  countless  nodes  on  a  global  scale.  While  the 
collection  of  data  has  already  increased  enormously  over  the  past  decade,  the  availability 
of  such  a  global  network  is  likely  to  increase  the  volume  of  data  by  several  orders  of 
magnitude.  Such  a  volume  of  raw  data  is  likely  to  choke  the  global  network  regardless  of 
any  advances  in  communication  and  computer  hardware  technology.  To  overcome  this 
very  real  problem  there  is  a  need  to  collect  data  in  context  so  that  only  the  data  that  are 
relevant  and  useful  are  collected  and  transmitted  within  the  networked  environment.  Most 
(if  not  all)  of  the  necessary  filtering  must  be  achieved  automatically  for  at  least  three 
reasons.  First,  organizations  cannot  afford  to  utilize  human  resources  for  repetitive  tasks 
that  are  tedious  and  require  few  human  intellectual  skills.  Second,  even  if  an  organization 
could  afford  to  waste  its  human  resources  in  this  manner  it  would  soon  exhaust  its 
resources  under  an  ever-increasing  data  load.  Third,  it  does  not  make  sense  for  an 
organization  to  ‘burn-out’  its  skilled  human  resources  on  low-level  tasks  and  then  not 
have  them  available  for  the  higher-level  exploitation  of  the  information  and  knowledge 
generated  by  the  lower  level  tasks. 

Finally,  the  increased  reliance  on  computer-based  information  systems  mandates  a  level 
of  reliability  and  security  that  cannot  be  achieved  through  manual  means  alone.  The 
alternative,  an  autonomic  computing  capability,  requires  the  software  that  controls  the 
operation  of  the  system  to  have  some  understanding  of  system  components  and  their 
interaction.  In  other  words,  autonomic  computing  software  demands  a  similar  internal 
information-centric  representation  of  context  that  is  required  in  support  of  the  knowledge 
management  activities  in  an  organization.  In  both  cases  the  availability  of  data  in  context 
is  a  prerequisite  for  the  reasoning  capabilities  of  software  agents  (i.e.,  the  automatic 
interpretation  of  information  by  the  computer). 

A  Framework  for  Assessing  Software  Capabilities 

Just  like  the  initial  conception  and  implementation  of  computing  devices  was  driven  by 
the  human  desire  to  overcome  the  limitations  of  manual  calculation  methods,  the 
advancements  in  computing  technology  during  the  past  50  years  have  been  driven  by  the 
desire  to  extend  the  usefulness  of  computer-based  systems  into  virtually  every  human 
activity.  It  is  not  surprising  that  after  several  orders  of  magnitude  increases  in  hardware 
performance  (i.e.,  computational  speed  and  data  storage  capacity  (Pohl  1998))  had  been 
achieved,  attention  would  gradually  shift  from  hardware  to  software. 

Increasingly  software  is  being  recognized  as  the  vehicle  for  computers  to  take  over  tasks 
that  cannot  be  completely  predefined  at  the  time  the  software  is  developed.  The  impetus 
for  this  desire  to  elevate  computers  beyond  data-processing,  visualization  and  predefined 
problem-solving  capabilities,  is  the  need  for  organizations  and  individuals  to  be  able  to 
respond  more  quickly  to  changes  in  their  environment.  Computer  software  that  has  no 
‘understanding’  of  the  data  that  it  is  processing  must  be  designed  to  execute  predefined 
actions  in  a  predetermined  manner.  Such  software  performs  very  well  in  all  cases  where 
it  is  applied  under  its  specified  design  conditions  and  performs  increasingly  poorly,  if  at 
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all,  depending  on  how  much  the  real  world  conditions  vary  from  those  design 
specifications.  Instead,  what  is  needed  is  software  that  incorporates  tools,  which  can 
autonomously  adapt  to  changes  in  the  application  environment. 

Adaptable  software  presupposes  the  ability  to  perform  some  degree  of  automated 
reasoning.  However,  the  critical  prerequisite  for  reasoning  is  the  situational  context 
within  which  the  reasoning  activity  is  framed.  It  is  therefore  not  surprising  that  the 
evolution  of  computer  software  in  recent  years  has  been  largely  preoccupied  with  the 
relationship  between  the  computational  capabilities  and  the  representation  of  the  data  that 
feed  these  capabilities.  One  could  argue  that  the  historical  path  from  unconnected  atomic 
data  elements,  to  data  structures,  relational  databases,  data  objects,  object-oriented 
databases,  object  models,  and  ontologies,  has  been  driven  by  the  desire  to  provide 
information  context  in  support  of  automated  reasoning  capabilities. 

However,  to  be  able  to  present  a  true  historical  perspective  of  the  evolution  of  software  it 
is  necessary  to  take  into  account  a  more  comprehensive  set  of  criteria.  In  fact,  there  are 
several  factors  that  have  in  the  past  and  are  continuing  to  contribute  to  the  evolution  of 
intelligent  software.  This  section  will  attempt  to  establish  a  set  of  categorization  criteria 
to  serve  as  a  framework  for  tracing  the  capabilities  of  software.  Since  these  capabilities 
are  closely  related  to  the  design  and  implementation  of  the  computer-based  environment 
within  which  the  software  is  required  to  operate,  the  proposed  framework  will  utilize 
system  architecture  as  a  yardstick  and  milestone  component.  The  following  eight  system 
architectures  have  been  selected  to  serve  as  milestones  for  the  assessment  of  software 
capabilities: 

•  Single  data-centric  applications  that  operate  in  a  stand-alone  mode  and 
receive  data  from  user  interaction  and  other  closely  coupled  sources  (e.g.,  data 
fdes  and  dedicated  databases). 

•  Confederation  of  linked  data-centric  applications  with  application-to- 
application  data  bridges.  Also  described  as  ‘stove-pipe’  systems  because  the 
system  components  are  essentially  hardwired  to  only  work  together  within 
their  confederation. 

•  Shared  database  systems  consisting  of  multiple  data-centric  applications  that 
are  able  to  share  data  between  themselves  and  a  common  repository,  through 
application-to-database  bridges.  The  repository  may  be  either  a  single 
database  or  a  distributed  database  facility. 

•  Distributed  expert  systems  with  dedicated  knowledge  bases  (i.e.,  rules)  and  a 
single  shared  fact  list  (i.e.,  data). 

•  Distributed  static  information-based  applications  with  collaborative  agents, 
capable  of  exchanging  data  with  external  data-centric  applications. 

•  Distributed  static  information-sharing  applications  with  collaborative 
agents,  capable  of  interoperating  at  the  ‘information’  level  with  other 
ontology-based  applications  and  capable  of  exchanging  data  with  external 
data-centric  applications. 

•  Distributed  extensible  information-sharing  applications  with  collaborative 
agents,  capable  of  interoperating  at  the  ‘information’  level  with  other 
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ontology-based  applications  and  capable  of  extending  their  internal 
information  representation  (i.e.,  ontology)  during  execution. 

•  Semantic  Web  services  capable  of  discovering  other  Web  services  and 
dynamically  configuring  themselves  into  distributed  systems  on  an  as-needed 
basis. 
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Fig.  1 1 :  Software  characterization  categories  and  their  capability  criteria 


The  software  capabilities  that  have  been  in  the  past  or  are  still  today  prevalently  applied 
in  each  of  these  system  architectures  are  characterized  within  six  capability  groups  as 
shown  in  Fig.l  1.  While  the  first  of  these  groups  (i.e.,  Group  (1)  System  Configuration)  is 
intended  to  describe  principal  architectural  features,  the  other  five  groups  are  focused  on 
the  degree  to  which  the  software  is  capable  of  representing  and  processing  data  with  or 
without  context  in  partnership  with  the  human  user.  Fundamental  in  this  respect  is  Group 
(2)  Internal  Representation.  The  manner  in  which  an  application  represents  the  data  that 
it  is  intended  to  manipulate  essentially  determines  the  level  of  software  intelligence  that 
the  application  is  capable  of  supporting.  Group  (2)  differentiates  among  applications  that 
represent  data  without  context  (i.e.,  ‘raw  data’  and  ‘objectified  data’),  applications  that 
provide  context  in  the  form  of  a  static  information  model  (i.e.,  sparse  information  model’ 
and  ‘rich  information  model’)  and  applications  with  information  models  that  are 
extensible  during  execution  (i.e.,  ‘extensible  information  model’  and  ‘dynamic 
information  model’).  The  remaining  four  groups  address  the  general  solution 
methodology  available  to  the  application,  its  decision-support  capabilities,  and  the  level 
of  internal  ‘understanding’  of  its  capabilities,  activities  and  intrinsic  nature.  The  divisions 
within  each  of  the  groups  will  be  defined  in  more  detail  during  the  discussion  of  each  of 
the  eight  system  architectures. 
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The  first  system  architecture  for  discussion  (Fig.  12)  is  representative  of  the  typical  early 
computer  applications,  namely  a  stand-alone  application  that  receives  all  of  its  data  from 
the  user  and/or  data  sources  that  are  considered  to  be  part  of  the  application.  Whether  or 
not  the  data  are  treated  as  discrete  elements  or  objects,  the  Internal  Representation 
includes  only  a  very  limited  set  of  relationships  and  therefore  lacks  context.  Under  these 
circumstances  the  Assistance  Capabilities  are  limited  to  predefined  solutions  utilizing 
static  algorithms,  no  internal  understanding  can  be  provided  by  the  representation  of  data 
without  relationships,  and  the  Intellectual  Capabilities  of  the  software  are  restricted  to 
‘remembering’  since  the  data  are  stored  in  the  computer.  The  second  system  architecture 
(Fig.  13)  adds  data  bridges  between  several  data-centric  applications.  Each  bridge  is 
simply  an  application-to-application  mapping  of  the  data  format  of  one  application  to  the 
other.  Therefore,  the  only  capability  that  this  architecture  adds  to  the  previously  discussed 
architecture  is  that  the  System  Configuration  supports  a  confederation  of  tightly  linked 
applications. 


Fig.12:  Single  data-centric  applications  Fig.  13:  Confederation  of  linked 

data-centric  applications 

The  shared  database  architecture  (Fig.  14)  constitutes  a  major  improvement  over  the  first 
two  system  architectures  by  separating  the  data  from  the  application  and  placing  the 
former  into  a  common  repository  that  is  external  to  all  of  the  applications.  The 
recognition  that  data  and  not  the  application  should  be  the  dominant  component  of  a  data- 
processing  environment  sets  the  stage  for  interoperability  and  intelligent  software. 
However,  it  does  not  directly  contribute  any  additional  capabilities  to  the  software 
criteria.  The  reason  is  the  absence  of  data  context,  and  this  applies  equally  to  the  three 
system  architectures  discussed  so  far. 

The  distributed  expert  system  architecture  shown  in  Fig.  15  on  the  other  hand,  by  virtue  of 
its  internal  knowledge  base  of  rules,  driven  by  a  shared  repository  of  facts,  adds  several 
new  capabilities  to  the  software.  Each  knowledge  base  provides  relationships  and 
therefore  represents  a  local  component  of  what  might  be  characterized  as  a  sparse 
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information  model.  This  model  provides  adequate  support  for  some  form  of  automated 
reasoning  within  the  typically  narrow  domain  of  each  expert  system.  Although  the  expert 
systems  (or  agents)  now  operate  as  tools  rather  than  predetermined  solutions,  their  rules 
are  nevertheless  predefined  and  typically  not  extensible  during  execution. 


Fig.  14:  Shared  database  systems  Fig.  15:  Distributed  expert  systems 

For  at  least  two  reasons  the  concept  of  expert  systems  represents  a  milestone  in  the 
transition  from  data-processing  to  information-centric  software.  First,  it  showed  that 
automated  rule-based  reasoning  is  in  fact  feasible  and  thereby  allowed  the  field  of 
artificial  intelligence  to  regain  some  confidence  after  its  earlier  failures.  Second,  the 
largely  opportunistic  pattern-matching  nature  of  an  expert  system  laid  the  foundations  for 
the  notion  of  demon-like  modules  with  particular  data  interests  that  could  be  triggered 
into  action  by  data  changes.  Over  the  next  decade  these  modules  developed  into  flexible 
software  agents  that  are  situated  in  some  environment  and  capable  of  autonomous  actions 
(Wooldridge  and  Jennings  1995,  Pohl  et  al.  2001  (32-33)).  It  was  highly  desirable  for 
these  agents  to  be  capable  of  acting  without  the  direct  intervention  of  human  users  (or 
other  agents),  thereby  providing  the  system  with  some  degree  of  control  over  its  own 
actions  and  internal  state.  The  ability  to  achieve  this  level  of  autonomous  behavior  was 
greatly  facilitated  by  situating  the  agent  in  a  sufficiently  well  represented  environment, 
which  it  can  monitor  and  act  upon.  Triggered  by  its  environment  the  agent  is  then  able  to 
respond  to  changes  in  the  environment,  exercise  intiative  through  goal-directed  reasoning 
capabilities,  and  utilize  the  services  of  other  agents  (including  the  human  user)  to 
supplement  its  own  problem-solving  capabilities  in  a  collaborative  fashion. 

The  desire  for  software  agents  to  perform  increasingly  more  valuable  and  human-like 
reasoning  tasks  focused  a  great  deal  of  attention  on  the  virtual  representation  of  the  real 
world  environment  in  which  the  agent  is  situated.  It  became  clear  that  the  reasoning 
capabilities  of  a  rule -based  software  agent  depend  largely  on  the  richness  of  the  virtual 
representation  of  this  physical  and  conceptual  environment.  Taking  advantage  of  the 
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capabilities  of  object-oriented  languages,  which  allow  objects  to  be  represented  as  classes 
with  attributes  and  relationships,  a  new  generation  of  application  software  with  internal 
object-based  information  models  was  bom  (Figs. 16,  17  and  18).  These  are  often  referred 
to  as  ontology-based  applications  and  are  typically  distributed  in  nature. 


It  should  be  noted  that  the  term  ontology  is  commonly  used  rather  loosely  as  a  synonym 
for  object  model.  Strictly  speaking,  however,  the  term  ontology  has  a  much  broader 
definition.  It  actually  refers  to  the  entire  knowledge  in  a  particular  field.  In  this  sense,  an 
ontology  includes  both  an  object  model  and  the  software  agents  that  are  capable  of 
reasoning  about  information  within  the  context  provided  by  the  object  model  (i.e.,  since 
the  agents  utilize  business  rules,  which  constitute  some  of  the  knowledge  within  a 
particular  domain).  In  this  paper  the  common  use  of  the  term  ontology  as  an  object  model 
(i.e.,  context)  is  implied. 
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Fig.  16:  Information-based  applications 


Fig.  1 7 :  Information-sharing  applications 


The  information-based  architecture  shown  in  Fig.  16  typically  consists  of  components 
(e.g.,  agents  and  user-interfaces)  that  communicate  with  each  other  through  an 
information-serving  collaboration  facility.  Each  component  includes  a  relevant  portion  of 
the  ontology  and  a  subscription  profile  of  the  kind  of  information  that  it  is  interested  in 
receiving  from  this  facility.  Since  the  components  have  at  least  a  limited  understanding  of 
the  real  world  situation  only  the  changes  in  the  situation  need  to  be  communicated  to 
them.  While  the  existence  of  a  subscription  service  obviates  the  need  for  computationally 
expensive  queries  in  most  cases,  the  ability  to  restrict  the  communication  to  changes  in 
information  also  greatly  reduces  the  amount  of  data  that  has  to  be  exchanged.  This 
applies  equally  to  the  information- sharing  architecture  and  the  extensible  information 
architecture  shown  in  Figs.  17  and  18,  respectively.  Also,  in  all  three  of  these  software 
architectures  system  capabilities  support  (and  promote)  decoupled  applications  that 
interact  via  these  services,  which  are  accessed  internally  through  clearly  defined 
interfaces.  Apart  from  simplifying  the  design  and  development  of  such  applications,  this 
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allows  services  to  be  seamlessly  replaced  as  long  as  the  replacement  service  adheres  to 
the  same  interface  definition. 


The  principal  differences  among  these  three  architectures  are  related  to  the  adaptability 
and  accessibility  of  the  ontology  within  each  of  the  information-centric  systems.  First,  in 
both  the  information-based  (Fig.  16)  and  the  information-sharing  (Fig.  17)  architectures 
the  ontologies  are  predefined  at  the  time  the  applications  are  compiled  and  cannot  be 
changed  during  execution.  While  it  is  certainly  possible  to  build  into  an  ontology  some 
degree  of  flexibility  that  allows  for  the  definition  of  variations  of  existing  object  types 
during  execution,  the  context-based  definition  of  new  objects  requires  the  application  to 
be  recompiled.  In  other  words,  the  ontology  is  essentially  static  after  the  application  has 
been  compiled.  In  the  extensible  information-sharing  architecture  shown  in  Fig.  18,  an 
application  is  able  to  gain  and  share  knowledge  in  its  interactions  with  other  applications 
that  have  similar  capabilities,  or  with  human  users.  The  ability  of  an  application  to  extend 
its  understanding  (i.e.,  to  increase  the  context  within  which  its  agents  are  able  to  reason 
about  changes  in  the  real  world  situation)  is  still  largely  a  subject  of  research.  It  involves 
the  construction  of  context  from  data  with  sparse  relationships,  which  intuitively  would 
appear  to  be  a  poor  approach.  However,  utilizing  lexical  (Fellbaum  1998)  and  algorithmic 
approaches  developed  in  the  natural  language  research  domain  (Pedersen  and  Bruce 
1998),  some  surprisingly  promising  progress  has  been  made  in  this  area  in  the 
commercial  arena  (Cass  2004). 


Fig.  1 8 :  Extensible  information-sharing 
applications 


Fig.  19:  Semantic  Web  services 


Second,  in  terms  of  accessibility,  the  subscription  capabilities  embedded  in  the 
components  of  an  information-based  system  can  be  equally  applied  across  multiple 
systems  by  having  the  information-serving  collaboration  facility  of  one  system  subscribe 
to  the  information-serving  collaboration  facility  of  another  system.  This  is  potentially  a 
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very  powerful  approach  that  allows  information-centric  systems  to  scale  as  clusters  of 
networks  within  a  networked  environment. 

The  software  architectures  described  so  far  (i.e.,  Figs.  12  to  18)  progressively  evolved 
from  stand-alone  systems  that  encapsulate  their  own  data,  to  systems  that  are  able  to 
share  data  based  on  predefined  formats  for  data  representation,  to  systems  that 
incorporate  rich  but  static  information  models  and  are  able  to  support  automated 
reasoning  capabilities,  to  systems  that  are  able  to  extend  their  internal  information  models 
in  collaboration  with  similar  ontology-based  external  systems.  Within  this  evolutionary 
path  the  transition  from  data-based  to  information-based  internal  representation  schemas 
is  the  enabling  step  that  has  endowed  software  with  increasingly  intelligent  capabilities. 
However,  the  fundamental  mechanism  for  achieving  these  capabilities  is  the  ability  to 
automatically  reason  about  changes  in  the  current  state  of  the  situation  described  by  the 
information  model.  Once  expert  systems  (Fig.  15)  had  demonstrated  that  reasoning 
capabilities  could  be  provided  by  conditional  rules  (i.e.,  a  knowledge  base  of 
productions)  and  triggered  by  changes  in  a  simple  fact-list,  it  became  clear  that  much 
could  be  gained  by  expanding  the  representational  capabilities  of  the  fact-list  and 
incorporating  in  it  many  of  the  relationships  that  were  formerly  encoded  in  the  rules  of 
the  knowledge  base.  This  contributed  to  the  formal  separation  within  an  application  of  the 
representation  (i.e.,  object  model  or  ontology)  and  the  logic  that  is  applied  to  this 
representation  by  agents.  While  initially  most  of  the  complexity  of  these  ontology-based 
applications  continued  to  reside  in  the  agents,  the  availability  of  more  powerful  modeling 
concepts  and  tools  is  gradually  allowing  more  and  more  of  the  complexity  to  be  moved 
from  the  agents  into  the  ontology.  This  suggests  a  trend  that  appears  to  mirror  the  earlier 
separation  of  an  application  from  the  data  it  is  designed  to  manipulate  (Fig.  14),  namely 
the  separation  of  the  information  representation  from  the  applications  that  incorporate 
reasoning  capabilities.  The  combination  of  this  trend  with  an  information-centric 
Internet-like  environment  will  cast  applications  into  the  role  of  capability-based  services. 

This  is  the  emerging  concept  portrayed  by  the  semantic  Web  services  architecture  shown 
in  Fig.  19.  However,  before  describing  this  software  architecture  it  is  necessary  to  briefly 
discuss  the  architecture  and  capabilities  of  the  existing  data-centric  Web  services.  They 
typically  comprise  a  Web-Server  that  utilizes  the  Hyper-Text  Transfer  Protocol  (HTTP) 
for  communication,  the  Universal  Description  Discovery  and  Integration  (UDDI) 
protocol  as  part  of  the  standard  definition  of  Web  services  registries,  and  a  Registry  that 
already  contains  an  entry  for  the  accessing  application  as  well  as  any  number  of  other 
Web  services.  UDDI  is  an  international  standard  that  defines  a  set  of  methods  for 
accessing  a  Registry  that  provides  certain  information  to  an  accessing  application.  For 
perhaps  historical  reasons  UDDI  is  structured  to  provide  information  about  organizations, 
such  as:  who  (about  the  particular  organization);  what  (what  services  are  available);  and, 
where  (where  are  these  services  available). 

The  Simple  Object  Access  Protocol  (SOAP)  defines  a  protocol  for  the  direct  exchange  of 
data  objects  between  software  systems  in  a  networked  environment.  It  provides  a  means 
of  representing  objects  at  execution  time,  regardless  of  the  underlying  computer 
language.  SOAP  defines  methods  for  representing  the  attributes  and  associations  of  an 
object  in  the  Extensible  Markup  Language  (XML).  It  is  actually  a  meta-protocol  based  on 
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XML  that  can  be  used  to  define  new  protocols  within  a  clearly  defined,  but  flexible 
framework. 

Web-Services  are  designed  to  be  accessed  by  software.  In  the  currently  prevalent  data- 
centric  software  environment  they  are  generally  clients  to  the  middleware  of  data  sources. 
The  middleware  collects  the  required  data  and  sends  them  back  to  the  Web  service, 
which  reformats  the  data  using  the  SOAP  protocol  and  passes  them  onto  the  requester. 
Depending  on  its  original  specifications,  the  requesting  application  will  have  the  data 
downloaded  on  disk  or  receive  them  directly  on-line.  If  the  Web  service  is  a  data-centric 
application  then  a  data-to-data  translation  must  be  performed  in  much  the  same  way  as  is 
necessary  when  passing  data  between  two  data-centric  applications. 

Returning  to  the  software  architecture  shown  in  Fig.  19,  the  emphasis  is  on  the  word 
semantic.  In  this  architecture  the  semantics  are  embedded  in  an  ontology,  which  provides 
the  necessary  context  for  automated  reasoning.  A  semantic  Web  service,  therefore,  is  an 
ontology-based  application  (may  be  mobile)  with  certain  capabilities.  Given  a  particular 
intent  it  seeks  the  services  that  it  determines  to  be  necessary  for  satisfying  this  intent. 
Having  found  one  or  more  such  Web  services  it  self-configures  itself  with  these 
discovered  services  into  a  temporary  system.  Depending  on  needs  and  circumstances  this 
transitory  system  may  reconfigure  itself  by  discarding  existing  members  when  their 
capabilities  are  no  longer  needed,  adding  new  members  when  other  requirements  arise,  or 
dissolving  itself  altogether  once  it  determines  that  its  intent  has  been  adequately 
executed. 

To  meet  these  capability  objectives  a  semantic  Web  service  reaches  the  highest-level 
criteria  in  all  but  one  of  the  six  software  characterization  categories  shown  in  Fig.  11  and 
13.  First,  it  operates  in  a  competitive  environment  where  it  can  select  a  service  from 
several  offering  candidates,  and  presumably  negotiate  the  terms  of  acceptance.  Second,  it 
incorporates  a  rich  and  extensible  information  model  that  will  change  dynamically  as  the 
semantic  Web  service  discovers,  collaborates  with,  and  shares  ontology  fragments  with 
its  transitory  partners.  This  provides  the  ability  to  create  and  maintain  a  desirable  degree 
of  common  understanding  within  the  self-configured  system.  Third,  by  virtue  of  this 
common  understanding  the  agents  of  each  member  of  the  system  are  able  to  collaborate 
beyond  the  boundaries  of  the  particular  semantic  Web  service  that  they  are  housed  in. 
Furthermore,  any  new  agents  that  may  be  generated  in  response  to  a  recently  emerged 
need  will  likewise  be  able  to  collaborate  globally  within  the  system. 

Forth,  the  agents,  which  constitute  the  primary  assistance  capabilities  of  the  system, 
become  highly  adaptable  tools.  They  are  extensible,  they  may  be  generated  dynamically 
during  execution  to  satisfy  emerging  new  needs,  and  they  can  be  implemented  to  operate 
in  a  mobile  mode.  Fifth,  the  collective  intellectual  capabilities  of  the  system  include  the 
ability  to  discover  capabilities  that  may  be  made  available  by  external  services  and  the 
ability  to  increase  its  understanding  of  context  by  extending  the  ontologies  of  one  or  more 
of  its  members  through  their  interaction  and  the  addition  of  new  members  to  the  system. 
It  can  be  argued  that  this  dynamic  acquisition  of  new  knowledge  is  a  form  of  learning, 
however,  it  does  not  necessarily  imply  an  ability  to  create  new  knowledge.  Whether  or 
not  the  semantic  Web  architecture  will  be  able  to  create  new  knowledge  is  very  much  a 
matter  of  conjecture  at  this  time. 
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Finally,  in  the  Internal  Understanding  category  the  semantic  Web  architecture  is  rated  to 
have  the  potential  for  reaching  the  highest  criterion,  ‘self-awareness’.  As  further 
explanation  it  should  be  noted  that  this  characterization  category  has  been  based  entirely 
on  the  representational  capabilities  of  ontologies,  since  the  author  is  not  aware  of  any 
alternative  method  for  creating  internal  understanding  in  software.  Ontologies  are  capable 
of  not  only  representing  physical  objects  such  as  buildings,  conveyances  (e.g.,  cars,  boats, 
aircraft),  supplies,  weapons,  and  organizations,  but  also  conceptual  objects  such  as  the 
notions  of  mobility,  threat,  privacy,  security,  consumability,  and  so  on.  This  has  been  the 
predominant  focus  of  ontologies  to  date.  However,  in  addition,  ontologies  are  able  to 
represent  the  behavioral  characteristics  and  relationships  of  the  components  of  the 
software  system  itself.  This  is  the  domain  of  autonomic  computing  discussed  previously, 
whereby  a  system  is  charged  with  continuously  monitoring  its  own  performance, 
exposure  to  intrusion,  vulnerability  to  failure  or  degradation,  and  implementing  remedies 
spontaneously  as  needs  arise. 

A  third  and  much  higher  level  of  representation  is  the  ability  of  a  system  to  express  to 
another  system  its  nature,  interests  and  capabilities.  What  is  implied  here  is  not  simply  an 
indication  that  this  is  a  software  system  written  in  the  Java  computer  language, 
supporting  the  following  interface  protocols,  and  listing  explicitly  defined  capabilities. 
This  kind  of  explicit  introduction  is  similar  to  the  directed  search  capabilities  that  are 
offered  by  the  query  facilities  of  any  database  management  system  available  today.  To 
fully  support  the  requirements  of  ‘discovery’  the  system  should  be  able  to  communicate 
its  nature,  interests  and  capabilities  in  a  conceptual  manner.  The  analogy  in  the  database 
domain  is  a  conceptual  search  capability,  where  the  target  of  the  search  is  only  vaguely 
defined  as  being  something  like  something  else  and  is  expected  to  extend  beyond  the 
boundaries  of  any  particular  database  or  database  management  system  (Pohl  et  al.  1999, 
69-74).  The  ability  to  represent  this  kind  of  ‘self-awareness’  in  an  ontology  appears  to  be 
well  beyond  current  knowledge  modeling  capabilities. 

The  Semantic  Web  Initiative 

It  is  unlikely  that  anyone  predicted  in  the  early  1970s  when  the  Internet  first  appeared  on 
the  foundations  of  the  ARPANET  project  funded  by  the  U.S.  Department  of  Defense 
Advanced  Research  Projects  Agency  (DARPA)  that  some  30  years  later  in  2003  the 
Internet  would  be  used  on  a  regular  basis  by  more  than  600  million  people  and  serve  as 
the  preferred  medium  for  close  to  (US)$4  trillion  in  business  transactions.  However, 
although  the  Internet  provides  almost  instant  global  connectivity  and  potential  access  to 
an  enormous  volume  of  information,  all  of  that  information  is  stored  in  a  low-level  form 
as  data.  As  a  result,  even  the  most  powerful  search  engines  can  do  little  more  than 
pattern-match  on  keywords  as  they  attempt  to  retrieve  user  requested  information.  The 
product  of  such  data  searches  is  typically  hundreds  of  information  source  references  that 
may  or  may  not  be  useful  to  the  human  user.  The  latter  may  then  have  to  spend  hours 
reviewing  each  source  to  determine  whether  it  is  relevant  to  the  purpose  of  the  search. 
This  was  not  the  intention  of  the  creators  of  the  World  Wide  Web  (Berners-Lee  and 
Fischetti  1999). 

There  is  a  valid  concern  that  the  more  successful  the  Internet  becomes  in  providing  global 
connectivity  to  millions  of  users,  with  a  corresponding  exponential  growth  in  the 
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availability  of  information,  the  less  useful  it  will  become  as  a  source  of  information. 
Succinctly  stated  the  evolution  of  the  Internet,  like  software  systems  in  general,  has  been 
driven  by  the  ability  of  computers  to  rapidly  manipulate  vast  amounts  of  data  without  any 
understanding  of  the  meaning  of  the  data  being  processed.  The  vision  of  the  Semantic 
Web  is  intended  to  overcome  this  serious  deficiency  by  making  the  information  on  the 
World  Wide  Web  understandable  by  computer  software.  Signs  of  this  vision  have 
become  evident  with  the  increasing  interest  in  adding  semantics  to  data. 

The  historical  development  of  data  manipulation  and  storage  techniques  first  showed  a 
preoccupation  with  efficiency,  leading  to  the  deletion  of  context  in  favor  of  the 
arrangement  of  data  into  neatly  packaged  records.  This  appeared  to  be  a  perfectly  logical 
approach  in  line  with  the  notion  that  the  application,  and  not  the  data,  is  the  enabler  of  the 
desired  functionality.  Accordingly,  the  data  requirements  were  encapsulated  in  the 
application,  and  even  when  programming  languages  began  to  acquire  object-oriented 
facilities  the  more  prominent  role  assigned  to  data  was  largely  hidden  from  the  users  deep 
inside  the  application. 

All  of  this  seemed  to  work  quite  well  until  the  need  for  interoperability  and  the  attendant 
requirement  for  the  exchange  of  data  among  applications  surfaced.  Two  problems  were 
quickly  recognized.  First,  since  each  application  controlled  its  own  data  schema  the 
linking  of  multiple  applications  required  application-to-application  data  mappings  that 
led  to  hardwired  systems.  It  soon  became  apparent  that  while  it  was  possible  to  maintain 
the  vertical  flow  of  data  within  each  of  these  stovepipe  systems,  it  was  inordinately 
difficult  to  exchange  data  horizontally  between  stovepipes.  The  second  problem  centered 
on  this  need  for  horizontal  interoperability:  How  to  exchange  data  between  two  stovepipe 
systems  so  that  the  receiving  application  will  be  able  to  process  the  imported  data  in  a 
useful  manner?  There  appeared  to  be  two  possible  approaches  for  addressing  this 
problem.  To  explicitly  predefine  the  data  exchange  format  and  content,  or  to  add 
meaning-identifiers  to  the  data.  The  first  approach,  while  providing  a  modest  level  of 
interoperability  in  the  short  term,  exacerbated  the  problem  in  the  long  term.  The 
hardwired  data  bridges  were  difficult  and  costly  to  maintain,  provided  little  (if  any) 
flexibility,  and  constituted  multiple  system  failure  points.  The  second  approach  led  to  the 
definition  of  standard  data  exchange  protocols  that  conveyed  to  the  receiving  application 
at  least  some  indication  of  the  meaning  of  an  imported  data  package.  Of  these  protocols 
the  Extensible  Markup  Language  (XML)  is  rapidly  gaining  widespread  acceptance.  XML 
provides  a  degree  of  syntactic  interoperability  through  nested  data  record  delimiters  (i.e., 
Unicode  characters),  data  meaning-identifiers  (i.e.,  tags),  and  links  to  other  resources 
(i.e.,  Uniform  Resource  Identifiers). 

Does  a  protocol  like  XML  convey  sufficient  meaning  to  support  horizontal 
interoperability?  The  answer  is,  no.  The  XML  elements  that  are  added  to  a  data  exchange 
package  to  convey  meaning  are  of  value  only  if  the  receiving  application  understands  the 
name  of  each  element.  For  example,  the  tag  name  “address”  is  only  useful  to  the 
receiving  application  if  it  interprets  that  name  to  have  the  same  meaning  as  the  meaning 
assumed  by  the  sending  application  (i.e.,  “address”  could  mean  street  address,  e-mail 
address,  object  reference  ID,  etc.).  However,  XML  does  provide  a  syntactic  foundation 
layer  on  which  other  layers  such  as  the  Resource  Description  Lramework  (RDF)  can  be 
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built.  The  combination  of  these  layers  will  serve  as  the  enabling  structure  of  what  is 
referred  to  as  the  Semantic  Web. 

The  vision  of  the  Semantic  Web  is  an  information-centric  environment  in  which 
autonomous  software  services  with  the  ability  to  interpret  data  imported  from  other 
services  are  able  to  combine  their  abilities  to  accomplish  some  useful  intent.  This  intent 
may  range  from  simply  finding  a  particular  item  of  information  to  the  more  sophisticated 
tasks  of  discovering  patterns  of  data  changes,  identifying  and  utilizing  previously 
unknown  resources,  and  providing  intelligent  decision-assistance  in  complex  and  time- 
critical  problem  situations.  An  example  of  such  an  environment  is  the  TEGRID  proof-of- 
concept  system  that  was  first  demonstrated  by  the  Collaborative  Agent  Design  Research 
Center  (CADRC)  during  an  Office  of  Naval  Research  Workshop  in  Washington  in 
September  2002  (Gollery  and  Pohl  2002).  A  brief  summary  of  this  demonstration  is 
provided  in  the  following  section. 


TEGRID:  An  Experimental  Web  Services  System 


The  principal  components  of  the  TEGRID  demonstration  are  ontology-based  Web 
services  that  are  capable  of  seeking  and  discovering  existing  Web  services,  extending 
their  own  information  models  through  the  information  model  of  any  discovered  Web 
service,  and  automatically  reasoning  about  the  state  of  their  internal  information  models. 
As  shown  in  Fig.20,  these  components  (referred  to  as  Cyber-Spiders  in  TEGRID)  consist 
of  three  principal  components:  a  Web  server;  a  semantic  Web  service;  and,  an 
information-centric  application. 


Fig.20:  Anatomy  of  a  Cyber-Spider 


I  Scenario! 

Since  Fall  2001  California  has  been  threatened  by 
intermittent  electric  power  shortages.  TEGRID  is 
designed  to  assist  the  Los  Angles  County  Sheriff's 
Department  to  respond  to  rotating  power  blackouts. 


|  Players  h 


^•^JEOB:  Emergency  Operations  Bureau 
O  LSS:  Local  Sheriff  Station 
Q  PSO:  Power  Supply  Organization 
i^^TCO:  Traffic  Control  Organization 
WSK:  Web  Services  Kiosk  (LA  County) 
RRT:  Rapid  Response  Team 


0 

Ml 


Fig.2 1 :  Cast  of  TEGRID  players 


The  Web  server,  utilizing  the  standard  Hypertext  Transfer  Protocol  (HTTP),  serves  as  the 
gateway  through  which  the  Cyber-Spider  gains  access  to  other  existing  Web  services. 
Existing  Web  servers  primarily  provide  access  to  Hypertext  Markup  Language  (HTML) 
data  sources  and  perform  only  simple  operations  that  enable  access  to  externally 
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programmed  functionality.  However,  these  simple  operations  currently  form  the  building 
blocks  of  the  World  Wide  Web. 

The  second  component  of  a  Cyber-Spider  is  a  semantic  Web  service  (i.e.,  a  Web  service 
with  an  internal  information  model).  A  Web  service  is  accessed  through  a  Web  server 
utilizing  standard  protocols  (e.g.,  UDDI,  SOAP,  WSDL,  SML)  and  is  capable  of 
providing  programmed  functionality.  However,  clients  to  a  standard  Web  service  are 
usually  restricted  to  those  services  that  implement  specific  predefined  interfaces.  The 
implementation  of  Web  services  in  the  Internet  environment  allows  organizations  to 
provide  access  to  applications  that  accept  and  return  complex  objects.  Web  service 
standards  also  include  a  limited  form  of  registration  and  discovery,  which  provide  the 
ability  to  ‘advertise’  a  set  of  services  in  such  a  way  that  prospective  client  programs  can 
find  services  that  meet  their  needs.  The  addition  of  an  internal  information  model  in  a 
semantic  Web  service  allows  the  storage  of  semantic  level  descriptions  (i.e.,  information) 
and  the  performance  of  limited  operations  on  these  semantic  descriptions.  In  other  words, 
the  semantic  Web  server  component  of  a  Cyber-Spider  is  capable  of  reasoning. 

The  third  component  of  a  Cyber-Spider  is  one  or  more  information-centric  applications. 
These  applications  are  designed  to  take  advantage  of  the  resources  provided  by  a  number 
of  semantic  Web  services,  enabling  them  to  reason  about  the  usefulness  of  each  service 
as  a  core  capability  within  a  more  sophisticated  set  of  discovery  strategies.  Moreover,  the 
application  component  is  able  to  construct  relationships  among  the  information  models  of 
different  services,  with  the  ability  to  integrate  services  without  requiring  agreement  on  a 
common  information  model. 

With  these  three  components  Cyber-Spiders  are  at  least  minimally  equipped  to  operate  in 
an  Internet  environment  as  autonomous  software  entities,  capable  of:  discovering  needed 
services;  accepting  services  from  external  offerers;  providing  services  to  external 
requesters;  gaining  context  through  an  internal  information  model;  automatically 
reasoning  about  available  information;  extending  their  information  model  during 
execution;  extending  their  service  capabilities  during  execution;  and,  learning  from  their 
collaborations. 

The  Cast  of  Players 

Based  on  the  scenario  described  in  Fig.21,  the  TEGRID  cast  of  players  includes  six 
semantic  Web  services:  the  Emergency  Operations  Bureau  (EOB)  of  the  Los  Angeles 
Sheriffs  Department;  several  Local  Sheriff  Stations  (LSS);  a  Power  Supply  Organization 
(PSO);  a  Traffic  Control  Organization  (TCO);  several  Rapid  Response  Teams  (RRT); 
and,  a  Los  Angeles  County  Web  Services  Kiosk  (WSK). 

Fundamental  to  each  player  are  three  notions.  First,  each  player  operates  as  an 
autonomous  entity  within  an  environment  of  other  players.  Most,  but  not  all  of  the  other 
players  are  also  autonomous.  This  requires  the  autonomous  players  to  be  able  to  discover 
the  capabilities  of  other  players.  Second,  each  autonomous  player  has  a  sense  of  intent  to 
accomplish  one  or  more  objectives.  Such  objectives  may  range  from  the  desire  to  achieve 
a  goal  (e.g.,  maintain  situation  awareness,  coordinate  the  response  to  a  time-critical 
situation,  or  undertake  a  predetermined  course  of  action  following  the  occurrence  of  a 
particular  event)  to  the  willingness  to  provide  one  or  more  services  to  other  players. 
Third,  each  player  (whether  autonomous  or  not)  is  willing  to  at  least  cooperate  with  the 
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other  players.  In  some  cases  the  level  of  cooperation  will  extend  to  a  collaborative 
partnership  in  which  the  partnering  players  contribute  to  the  accomplishment  of  a 
common  objective.  In  other  cases  the  cooperation  may  be  limited  to  one  player  providing 
a  service  to  another  player,  without  any  understanding  or  interest  in  the  reason  for  the 
service  request. 

To  operate  successfully  in  such  an  autonomous  Internet-based  environment  a  Cyber- 
Spider  player  should  be  endowed  with  the  following  capabilities: 

1.  Subscribe  to  information  from  external  sources  (e.g.,  alerts,  ontology  extensions). 

2.  Accept  subscriptions  from  external  clients. 

3.  Dynamically  change  its  subscription  profile. 

4.  Extend  its  internal  information  representation. 

5.  Extend  its  own  service  capabilities. 

6.  Generate  new  agents  for  its  own  use. 

7.  Describe  its  own  service  capabilities  to  external  clients. 

8.  Seek,  evaluate  and  utilize  services  offered  by  external  clients. 

9.  Provide  services  to  external  clients. 

10.  Describe  its  own  (intent)  nature  to  external  clients. 

The  Cyber-Spiders  in  TEGRID  are  capable  of  demonstrating  eight  of  these  ten  desirable 
capabilities.  The  ability  of  a  Cyber-Spider  to  dynamically  change  its  subscription  profile, 
while  technically  a  fairly  simple  matter,  was  not  implemented  because  it  is  not  used  in  the 
demonstration  scenario.  The  ability  of  a  Cyber-Spider  to  describe  its  own  nature  to 
external  clients,  on  the  other  hand,  is  technically  a  much  more  difficult  proposition.  It 
will  require  a  Cyber-Spider  to  have  an  understanding  of  its  personality  as  a  collective 
product  of  its  internal  information  model  and  the  relationship  of  that  model  with  the 
external  world.  At  best  this  must  be  considered  a  challenging  research  area  that  is  beyond 
the  current  capabilities  of  information-centric  software  systems. 

The  Capabilities 

The  objective  of  the  TEGRID  scenario  is  to  demonstrate  the  discovery,  extensibility, 
collaboration,  automatic  reasoning,  and  tool  creation  capabilities  of  a  distributed,  just-in- 
time,  self-configuring,  collaborative  multi-agent  system  in  which  a  number  of  loosely 
coupled  semantic  Web  Services  associate  opportunistically  and  cooperatively  to 
collectively  provide  decision  assistance  in  a  crisis  management  situation.  Specifically, 
these  capabilities  are  defined  as  follows: 

Discovery:  Ability  of  an  executing  software  entity  to  orient  itself  in  a  virtual 
cyberspace  environment  and  discover  other  software  services. 

Extensibility:  Ability  of  an  executing  software  entity  to  extend  its  information 
model  by  gaining  access  to  portions  of  the  information  model  of  another 
executing  software  entity. 

Collaboration:  Ability  of  several  semantic  Web  Services  to  collaboratively 

assist  each  other  and  human  users  during  time  critical  decision-making  processes. 
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Reasoning:  Ability  of  a  software  agent  to  automatically  reason  about  events  in 
near  real-time  under  time  critical  conditions. 

Tool  Creation:  Ability  of  a  semantic  Web  Service  to  create  an  agent  to 
perform  specific  situation  monitoring  and  reporting  functions. 

The  reasoning  capabilities  available  in  TEGRID  are  performed  by  software  agents  that 
are  components  of  the  players  (i.e.,  the  Cyber-Spiders).  In  other  words,  agents  are 
predefined  clients  within  player  systems  and  perform  internal  functions  that  are  necessary 
for  the  particular  player  to  deliver  its  services  and/or  accomplish  its  intent.  The  following 
agents  (i.e.,  collaborative  tools)  are  available  in  the  current  TEGRID  implementation: 

Risk  Agent:  Assists  the  Emergency  Operations  Bureau  to  identify  high- 
risk  entities  in  the  jurisdictional  region  of  an  activated  Local  Sheriff 
Station. 

Deployment  Agent:  Assists  the  Emergency  Operations  Bureau  to 
determine  whether  Rapid  Response  Team  support  is  required  for  a 
particular  activated  Local  Sheriff  Station. 

Power  Level  Agent:  Assists  the  Power  Supply  Organization  to  determine 
if  the  electric  power  demand  has  exceeded  supply. 

Situation  Agent:  Assists  the  Emergency  Operations  Bureau  to  prepare 
and  update  its  Status  Report. 

Station  Monitor  Agent:  Assists  the  Emergency  Operations  Bureau  to 
identify  all  Local  Sheriff  Stations  that  will  experience  power  blackouts 
during  the  current  and  next  blackout  cycle. 

Status  Agent:  Assists  a  Local  Sheriff  Station  to  prepare  and  update  its 
Situation  Status  Report. 

Local  Station  Agent:  Assists  a  Local  Sheriff  Station  to  determine  whether 
sufficient  local  resources  are  available  to  deal  with  current  conditions. 

Scheduling  Agent:  Assists  the  Emergency  Operations  Bureau  to  assign 
Rapid  Response  Teams  and  equipment  to  situations  requiring  their 
involvement. 

Incident  Agent:  Assists  the  Emergency  Operations  Bureau  to  monitor  the 
response  to  a  particular  situation  supported  by  one  or  more  of  its  Rapid 
Response  Teams. 

Routing  Agent:  Assists  the  Traffic  Control  Center  to  determine 
alternative  routes  to  a  particular  situation  location. 

Demonstration  Summary 

Since  the  complete  TEGRID  demonstration  scenario  has  been  described  elsewhere 
(Gollery  and  Pohl  2002)  it  will  suffice  here  to  summarize  some  typical  events  and 
automated  reactions. 

Orientation:  The  players  orient  themselves  by  accessing  one  or  more  directories 
of  available  services  and  registering  an  information  subscription  profile  with  those 
services  that  they  believe  to  be  related  to  their  intent  (Fig.22). 
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Fig.22:  Orientation  and  discovery 


Fig.23:  Information  subscription 


Subscription:  The  players  access  the  services  that  they  require  to  achieve  their 
intent,  register  appropriate  subscription  profdes,  and  query  for  information  that 
they  believe  to  have  a  need  for  (Fig.23).  For  example,  the  Emergency  Operations 
Bureau  registers  a  subscription  profde  with  each  Local  Sheriff  Station,  which 
includes  all  current  police  unit  locations,  mission  completion  events,  new  mission 
events,  and  any  information  changes  relating  to  the  availability  of  its  Rapid 
Response  Teams.  Then  queries  each  Local  Sheriff  Station  for  all  information 
relating  to  its  Rapid  Response  Teams  and  extends  its  information  model.  Finally, 
registers  subscription  profdes  with  each  Rapid  Response  Team,  the  Power  Supply 
Organization,  and  the  Traffic  Control  Organization. 

Collaboration:  The  Power  Supply  Organization  first  alerts  its  subscribers  that  a 
rolling  power  blackout  condition  is  imminent  (i.e.,  will  commence  per  predefined 
schedule  within  15  minutes)  and  subsequently  alerts  its  subscribers  that  the  rolling 
power  blackout  has  commenced.  The  Emergency  Operations  Bureau  (EOB) 
utilizes  its  Situation  Agent  to  prepare  the  first  version  of  the  ‘EOB  Situation 
Status  Report’.  Then  alerts  all  Local  Sheriff  Stations,  in  whose  jurisdictions  the 
next  scheduled  set  of  blackouts  will  occur,  to  prepare  for  potential  deployment. 
And,  finally,  warns  the  Rapid  Response  Teams  assigned  to  assist  the  Local  Sheriff 
Stations  in  whose  jurisdictions  the  next  set  of  blackouts  are  scheduled  to  occur,  to 
prepare  for  potential  deployment.  Consequently,  all  activated  Local  Sheriff 
Stations  utilize  their  Status  Agents  to  prepare  the  first  version  of  their  ‘Situation 
Status  Reports’,  the  Local  Sheriff  Stations  in  whose  jurisdiction  the  next  set  of 
blackouts  is  scheduled  to  occur,  prepare  for  deployment. 


Demonstration  Results 

The  objectives  of  the  TEGRID  project  were  three-fold.  First,  to  explore  the  primary 
capabilities  that  would  be  required  of  semantic  Web  services  operating  as  largely 
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autonomous  decision-support  components  in  a  self-configuring,  just-in-time,  intelligent 
decision-assistance  toolkit  of  collaborating  software  agents.  Second,  to  determine  if  the 
currently  available  information-centric  software  technology  could  support  at  least  basic 
(i.e.,  meaningful  and  useful)  implementations  of  these  required  capabilities.  And,  third,  to 
build  a  working  experimental  system  that  could  serve  as  a  test-bed  for  longer  term 
research  studies  focused  on  the  behavioral  characteristics  of  self-configuring  intelligent 
systems  in  general,  and  the  ability  of  such  systems  to  deal  with  specific  kinds  of  dynamic 
and  complex  problem  situations. 

The  demonstration  showed  that,  today  at  a  base  level  of  functionality  and  in  the  near 
future  at  a  much  more  sophisticated  level,  a  Semantic  Web  environment  will  be  able  to 
support  semantic  Web  services  with  the  ability  to:  discover  desired  existing  external 
services;  accept  and  utilize  services  from  external  offerers;  provide  services  to  external 
requesters;  gain  understanding  through  the  context  provided  by  an  internal  information 
model;  automatically  reason  about  available  information  within  the  context  of  the 
internal  information  model;  extend  the  internal  information  model  during  execution; 
spontaneously  generate  new  agents  during  execution  as  the  need  for  new  capabilities 
arises;  and,  learn  from  the  collaborations  that  occur  within  the  cyberspace  environment. 
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Posturing  to  Exploit  the  Power  of  Emerging  Technology 


MajGen.  Bradley  M.  Lott,  USMC 

Deputy  Commanding  General 

Marine  Corps  Combat  Development  Command,  Quantico,  VA 


When  I  first  received  the  invitation  to  present  at  this  Office  of  Naval  Research  (ONR)  conference 
it  occurred  to  me  that  I  should  address  the  question  of  how  best  we  in  the  Department  of  Defense 
(DoD)  should  posture  ourselves  to  accept  the  rapidly  emerging  technology,  particularly  the 
information  technology  (IT)?  What  can  we  do?  Are  we  ready  to  accept  this  technology? 

First,  I  would  like  to  take  about  10  to  15  minutes  to  set  the  stage  for  where  DoD  is  right  now,  at 
least  where  the  Marine  Corps  is  right  now,  and  what  I  have  been  preaching  as  I  have  been  going 
out  and  talking  with  groups,  and  what  I  have  written  for  publication.  This  will  give  you  a  sense 
of  where  the  push  is  in  DoD.  Then  we  will  take  a  look  at  the  impediments  to  our  accepting  the 
technology,  the  precise  response  or  what  we  have  to  do  to  change,  and  then  I  will  wrap  it  up  with 
a  vision.  I  love  the  opportunity  to  toss  this  vision  out  and  let  you  all  have  it  to  chew  on. 

As  we  look  across  the  Department  for  solutions  to  problems  that  are  revealed  by  our  ever 
increasing  appetite  for  more  and  more  information,  we  are  confounded  by  the  speed  at  which 
information  comes  to  us.  It  is  very  dynamic  information,  it  is  continuously  changing  and  coming 
at  us  very  quickly.  We  don’t  yet  have  the  systems  to  coalesce  that  information  and  display  it  to 
us.  Therefore,  we  end  up  with  a  biowave  of  information  in  a  very  dynamic  environment.  That 
spells  disaster  all  by  itself.  What  we  need  is  some  assistance  in  processing  all  that  data  into 
actionable  information,  or  better  still,  into  actioned  information.  Too  often  we  become 
mesmerized  by  the  fancy  point  and  click  GUIs  that  are  put  on  our  old  systems,  and  we  don’t 
really  notice  that  we  are  actually  doing  more  work  than  we  did  before.  We  are  just  doing  the 
work  on  a  pretty  face.  That  is  sort  of  akin  to  having  difficulty  managing  your  schedules  and 
getting  the  latest  and  greatest  leather-bound  organizer  with  a  nice  golden  pen.  It  is  not  going  to 
make  the  schedule  any  better.  Instead,  I  am  just  going  to  spend  more  time  working  on  my 
schedule.  What  we  really  need  from  industry  is  a  solution  that  will  help  to  relieve  us  from  some 
of  the  mundane  tasks  and  present  the  information  to  us.  Perhaps,  even  make  some  intelligent 
recommendations  or,  better  still,  take  some  action.  Most  importantly  such  capabilities  should 
take  complex  situations  that  are  very  dynamic  and  come  back  with  either  actioned  or  actionable 
information. 

For  example,  consider  the  virtues  of  advanced  or  intelligent  computer-aided  design  (CAD) 
software  that  is  used  in  manufacturing.  You  know,  the  kind  of  software  that  is  capable  of 
selecting  the  appropriate  material,  sizing  components,  automatically  calculating  the  correct 
angles,  checking  code  compliance,  estimating  costs,  and  taking  into  account  all  of  those  variables 
that  change  every  time  you  go  from  aluminum  to  steel  or  some  other  kind  of  alloy.  Those 
decisions  can  all  be  made  the  moment  the  stylus  touches  the  screen.  It  is  an  incredible  process.  I 
have  a  son  who  is  an  engineer  at  Ford  Motor  Company.  I  have  been  to  his  office  and  watched 
him  and  his  colleagues  as  they  use  the  system.  It  is  an  incredible  capability,  which  provides 
access  to  information  that  has  been  enhanced  by  a  computer-based  reasoning  tool.  It  is  not  Hal 
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9000,  the  errant  artificial  intelligence  from  A  Space  Odyssey.  A  human  engineer  is  still  doing  the 
design  work,  but  the  engineer  has  been  enabled  by  access  to  information  that  has  already 
considered  many  of  the  variables  that  impact  the  final  design  solution. 

If  our  manufacturing  industry  did  not  have  this  capability,  it  would  probably  go  out  of  business. 
Right  now,  at  least  the  high  end  of  ship  building  and  manufacturing  would  be  noncompetitive, 
without  it.  So,  industry  is  putting  a  lot  of  effort  into  that  area.  We  are  not,  and  the  question  is 
why  is  DoD  not  putting  the  same  level  of  effort  into  that  area?  In  respect  to  automation  solutions, 
we  in  DoD  seem  to  be  content  with  just  speeding  up  the  existing  process,  going  a  little  faster,  or 
seeing  a  prettier  picture.  In  our  more  creative  moments  we  may  become  involved  in  designing 
some  algorithms  to  determine  if  we  are  staying  within  some  boundaries  or  if  we  are  doing  things 
fairly  efficiently,  but  rarely  do  we  ever  ask  the  computer  software  to  really  dig  in  and 
automatically  reason  about  a  problem.  Quite  frankly  I  could  probably  count  all  those  kind  of 
capabilities  on  one  hand. 

Now  we  are  going  get  to  what  I  believe  you  are  really  interested  in.  Are  we  afraid  of  Hal?  Is  that 
the  problem?  Or,  is  it  just  that  this  black  box  voodoo  escapes  our  confidence?  Is  it  that  we 
cannot  believe  that  this  machine  can  actually  reason  and  give  us  some  valuable  opinions  or 
recommendations,  or  maybe  even  solutions?  We  certainly  do  not  appear  to  understand  the 
potential  of  the  computer  to  function  intelligently.  There  are  too  many  of  us  that  simply  refuse  to 
accept  the  idea  that  this  plastic  box  sitting  beside  our  desk  can  function  intelligently.  It  is  really 
important  that  we  think  about  that  for  just  a  second.  We  are  going  to  come  back  to  this  question 
later  when  I  suggest  how  we  have  to  posture  ourselves  to  better  receive  this  emerging 
technology.  We,  in  DoD,  really  need  to  understand  this  technology  that  you  (i.e.,  industry)  have 
and  that  you  are  working  on  and  that  you  are  developing.  I  need  to  look  at  every  single 
automation  requirement  that  comes  through  my  office  from  two  perspectives:  (1)  from  the 
vantage  point  of  the  Marine  Corps  Combat  Development  Command;  and,  (2)  as  a  Marine  Corps 
representative  on  the  Joint  Capabilities  Board  in  the  JROC  system.  Every  single  system  that 
comes  through  should  be  bounced  against  the  question:  Does  this  system  just  speed  up  the 
process  and  make  it  a  little  easier,  or  does  it  go  the  full  measure  and  rise  to  the  level  of  intellect 
and  our  ability  to  reason?  If  it  does  not  then  we  ought  to  ask  ourselves  why  we  have  accepted 
dumb  technology,  and  look  for  better  technology.  It  has  to  be  that  forceful.  Right  now  we  don’t 
have  a  forcing  function  to  make  it  happen.  Yet  I  am  suggesting  that  if  that  question  were  to  be 
asked  in  the  requirements  process,  then  that  could  be  the  forcing  function. 

For  those  who  are  afraid  of  the  new  technology,  I  would  suggest  that  the  aerospace  industry  is 
well  into  it.  Every  time  you  fly  in  an  airplane  you  are  relying  on  this  kind  of  technology.  These 
airplanes  fly  in  a  super-dynamic  environment,  with  constantly  changing  weather  conditions, 
threat  conditions,  traffic,  and  many  other  factors.  Yet,  those  companies  manage  those  airplanes 
to  the  dollar  (probably  to  the  penny)  in  terms  of  performance.  They  know  exactly  when  to  speed 
up,  slow  down,  to  change  altitude,  to  take  advantage  of  different  weather,  and  so  on.  The  guys  up 
in  front,  the  pilots,  are  really  in  my  opinion  information  management  experts.  They  are  receiving 
lots  of  information.  Some  of  the  information  is  automatically  translated  into  actions,  without  the 
knowledge  of  the  pilot.  Sometimes  he  is  given  a  follow-up  message  that  says  “I  just  did 
something”.  Particularly  in  our  new  airplanes,  without  the  computer  taking  immediate  actions  the 
airplane  would  cease  to  fly;  -  that  is  actioned  information.  Hal  is  in  that  airplane  that  you  are 
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flying  in.  So,  for  those  who  may  be  afraid  of  artificial  intelligence  and  these  reasoning 
capabilities,  there  are  airplanes  out  there  that  you  are  flying  in  that  depend  on  these  capabilities. 

Why  can’t  we  take  that  same  technology  and  build  it  into  our  deployment  systems  or  tactical 
operations  systems  or  budget  development  systems?  Why  can’t  these  systems  have  an 
ontological  brain;  -  a  logic  that  includes  characteristics  and  interrelationships?  The  answer  is  that 
we  can  have  the  technology,  it’s  do-able.  If  we  had  a  machine  that  could  help  with  some  of  the 
reasoning  tasks,  particularly  in  a  very  dynamic  environment,  then  that  could  be  very  important. 
Let’s  take  that  really  mundane  budgeting  task.  This  is  usually  a  late  Friday  afternoon  kind  of  drill 
that  comes  as  a  “what  if’  request.  “What  if  we  gave  you  an  extra  two  million  dollars,  where 
would  you  put  it  to  get  the  most  impact?  Have  that  response  to  me  by  Monday  morning.”  We  can 
handle  those  drills  and  we  do  it  on  the  backs  of  hardworking  people  with  stubby  pencils.  What  if 
we  had  a  machine  that  could  do  this  in  a  very  dynamic  environment,  and  come  back  to  us  with  an 
answer  “. . .  yes,  that  looks  good  but  what  about  these  third  order  effects  down  here?”  A  machine 
that  could  perform  this  task  so  quickly  that  it  could  be  measured  in  seconds,  and  not  hours  or 
days.  A  machine  that  can  look  at  capability  sets  in  relationship  to  each  other  and  the  problem  as  a 
whole;  -  not  a  piece  of  equipment  but  the  capability  that  it  represents. 

It  is  an  intriguing  thought  to  have  a  system  that  is  capable  of  categorizing  actions.  Some  of  these 
actions  would  be  acted  upon  without  our  explicit  knowledge.  We  could  call  this  actioned 
information.  The  system  would  also  do  other  things  such  as  letting  me  set  a  threshold  so  I  could 
say  “...  based  on  dollars  or  distance  or  time  or  risk  or  whatever  the  threshold  measurement  is 
such  and  such”.  I  could  set  the  threshold  where  I  am  comfortable  and  the  machine  would 
automatically  action  on  information  below  that  threshold.  There  would  be  many  other  options 
that  would  be  continuously  available,  displayed  like  in  the  cockpit  of  an  airplane  in  a  manner  that 
would  be  sensory  and  friendly;  -  that  I  could  absorb  quickly  and  easily  in  a  combat  operations 
center. 

Well  that  is  an  interesting  thought.  If  only  I  could  have  a  system  that  can  do  that  for  me.  Now  my 
mind  begins  to  race:  Where  can  I  employ  that  kind  of  system?  Can  I  put  it  in  a  tactical  Command 
and  Control  Center?  The  problem  is,  if  we  now  leave  this  thought  just  kind  of  loitering  around 
here  in  our  cranial  air  space  and  call  it  an  intriguing  thought,  then  we  find  ourselves  right  back  to 
where  we  started.  We  are  sub-optimized  within  our  own  GUI-enhanced  tailored  systems.  It  can’t 
remain  just  an  interesting  thought.  We  have  to  do  something  with  this.  Personally,  I  don’t  think 
we  have  even  scratched  the  surface  of  the  potential  capabilities  of  these  intelligently  operating 
computers.  I  don’t  think  we  have  really  scratched  the  surface  of  what  we  could  do  with  these 
machines.  In  practical  terms,  our  fear  of  Hal  or  the  black  box  voodoo  is  holding  us  hostage  to  a 
high  speed  old  plane  kind  of  mentality.  We  just  think  that  the  more  data  we  receive,  the  more  we 
pile  in,  the  more  we  stack  up  and  put  on  spreadsheets,  the  better  a  job  we  will  do.  Perhaps  we 
can  organize  it  a  little  better  and  put  a  better  face  on  it,  and  that  will  do  a  better  job.  It  has  been 
argued  that  during  World  War  II  General  Patton  dealt  with  about  300  bits  of  information  that 
came  to  him  each  day.  This  is  the  information  over  which  he  had  some  influence  and  on  the  basis 
of  which  he  could  take  some  actions.  If  you  really  think  about  it,  Generals  in  the  field  will  be 
fully  engaged  18  to  20  hours  per  day.  In  those  18  to  20  hours,  Patton  is  going  to  take  300  pieces 
of  information  that  he  is  going  to  do  something  with.  Let’s  do  the  mathematics,  he’s  busy,  and  by 
all  accounts  General  Patton  was  a  very  capable  general  officer.  Now  let’s  consider  the  same  level 


29 


of  command  in  Operation  Iraqi  Freedom  (OIF)  with  having  to  deal  with  about  600,000  bits  of  the 
same  kind  of  information.  Now  it  doesn’t  matter  what  the  actual  numbers  are,  we  all  know  that 
we  have  a  lot  more  information  available  today  than  we  had  back  then  when  it  was  a  matter  of 
just  how  fast  the  runner  could  get  back  there  with  his  canvas  bag  and  open  it  up  and  give  him  the 
information.  General  Conway  during  OIF  was  just  deluged  with  information,  and  his  staff  was 
just  buried  in  information. 

What  bothers  me  most  about  this  is  that  it  is  good  that  the  information  is  coming  in.  Everybody 
did  a  wonderful  job  in  gathering  that  information  and  sending  it  to  us.  However,  I  don’t  think 
that  General  Conway  can  process  much  more  information  than  General  Patton  did,  -  maybe  300 
pieces  a  day  and  that  leaves  all  the  rest  without  action.  The  question  that  comes  into  my  business 
mind  is:  What’s  the  opportunity  cost?  What  did  I  lose  because  I  didn’t  take  advantage  of  all  of 
that  information?  Now  maybe  some  of  you  might  look  at  it  and  say  I  would  do  nothing.  There  is 
no  action  that  I  can  take  that  would  change  anything.  However,  I  would  suggest  that  if  you  could 
take  all  of  those  little  bits  of  information  and  put  them  together  and  make  only  a  5% 
improvement  on  the  battlefield,  in  terms  of  ammunition  or  fuel  consumption  or  distance  traveled 
or  if  it  saved  the  life  of  one  Marine,  then  it  is  worthwhile.  How  can  we  let  that  information  go  by 
without  action,  if  it  could  save  the  life  of  one  Marine,  -  it  would  be  unconscionable. 

Our  current  inclination  is  to  focus  on  prioritizing  all  of  that  information.  We  triage  it  when  it 
comes  in  to  the  combat  operations  center  and  we  act  first  on  what  we  think  is  most  important, 
and  we  work  until  time  expires  or  we  expire.  The  truth  is  that  we  are  never  sure  that  we  are 
getting  the  most  important  information.  It  is  mostly  a  matter  of  ‘first  in  first  out’.  This  technique 
may  be  valid  if  you  are  in  a  gator  infested  swamp  and  you  are  just  trying  to  stay  alive  for  a  few 
minutes.  It  would  have  to  be  acceptable  if  that  is  the  only  tool  you  have,  however,  I  would  like  to 
suggest  that  we  have  some  other  tools  that  we  should  take  advantage  of.  We  live  in  a  time  where 
information  is  exponentially  more  available  than  it  was  in  years  past.  Also,  we  have  problems 
that  require  more  precision  solution  than  ever  before.  Just  for  a  moment  let’s  talk  about  precision 
and  what  the  expectation  are  for  weapons.  Today,  we  don’t  tolerate  a  weapon  being  a  minute  too 
early  or  a  minute  too  late.  The  delivery  must  be  precisely  on  time,  and  that  is  precisely  when 
somebody  is  transmitting  on  a  radio  or  precisely  when  a  group  begins  a  meeting.  We  want 
precision  to  the  minute,  or  even  to  the  second,  so  that  we  can  measure  opportunity  costs.  If  you 
could  look  at  all  those  decisions  every  day  that  we  didn’t  make,  if  you  could  sort  through  that 
data,  then  I  bet  you  could  quantify  the  opportunity  costs  of  not  looking  at  that  data.  With  that  in 
mind,  we  really  need  to  avail  ourselves  of  the  benefits  of  computer  software  with  intelligent 
reasoning  capabilities. 

So  the  question  is,  how  do  we  get  there?  I  believe  that  there  are  already  some  intelligent  systems 
available  and  others  are  on  the  threshold  of  implementation.  The  problem  is  that  we  have  to 
overcome  the  inertia  of  some  old  think  bureaucracy  that  is  out  there  alive  and  well.  This  is  a 
tough  opponent  to  have  to  fight  every  single  day.  However,  the  future  is  wide  open  with 
opportunities  and  our  minds  must  be  equally  open  if  we  are  going  to  grasp  the  very  crisp  edge  of 
the  possible.  This  is  essential  as  we  in  the  Marine  Corps  approach  the  complexities  of  concepts 
such  as  sea-basing,  where  schemes  of  maneuver  with  an  increased  number  of  variables  need  to 
be  executed  precisely  in  very  time  constrained  environments  with  fewer  and  fewer  resources.  All 
of  this  is  becoming  increasingly  difficult  and  we  need  help  with  this  increasing  complexity. 
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My  intent  in  advocating  these  new  capabilities  in  DoD  and,  in  particular  in  the  Marine  Corps,  is 
to  challenge  the  old  ways  with  a  generation  of  adaptive  decision  support  tools.  We  have  a  true 
transformation  technology  on  our  doorstep.  It  is  here  now  and  we  have  to  decide  what  we  are 
going  to  do  with  it.  Are  we  going  to  kick  it  into  the  curb  or  welcome  it  in?  We  have  to  have  the 
courage  to  make  the  decision  now.  I  know  that  there  are  some  of  us  who  are  process-oriented.  I 
fully  understand  that  just  introducing  a  technology  is  not  enough.  We  also  have  to  review  all  of 
the  processes.  If  you  are  willing  to  accept  the  fact  that  this  technology  is  out  there  and  you  want 
to  be  able  to  use  it,  then  you  are  going  to  have  to  take  a  look  at  your  existing  processes.  You 
have  to  ask  yourself,  do  I  have  to  re-examine  them  and  perhaps  change  the  way  I  am  doing 
things.  It  is  not  enough  to  simply  make  everything  go  faster.  Let’s  go  the  full  measure  and  also 
review  the  processes  as  we  apply  the  technology. 

Perhaps  the  greatest  challenge  that  we  face  today  is,  tomorrow.  We  are  simply  not  postured  to 
face  tomorrow  today.  We  tend  to  put  off  dealing  with  tomorrow  until  tomorrow.  I  see  our 
difficulty  with  posturing  as  being  related  to  two  aspects  of  our  organizations,  their  cultural  state 
and  their  willingness  to  commit  resources.  Let’s  talk  first  about  the  cultural  state.  Jim  Collins 
writes  in  his  fabulous  book  Good  to  Great  "...  good  to  great  companies  think  differently  about 
the  role  of  technology.”  They  never  use  technology  as  a  primary  means  of  igniting 
transformation,  yet  paradoxically  they  are  the  pioneers  in  the  application  of  carefully  selected 
technologies.  We  seem  to  find  it  difficult  to  embrace  technology.  We,  that  is  DoD  and  in 
particular  the  Marines,  are  generalists.  The  volume  of  available  technologies  is  overwhelming  to 
us.  We  go  to  a  trade  shows  and  we  are  absolutely  intimidated.  We  usually  wait  for  somebody  to 
take  the  technology  and  put  it  into  a  product  and  then  knock  on  the  door  and  sell  us  the  product. 
Unfortunately,  that  does  not  take  the  most  advantage  of  the  technology,  because  the  product  may 
not  cover  the  entire  range  of  our  requirements. 

Now  let’s  look  at  the  issue  of  organizational  commitment.  The  nasty  truth  about  commitment  in 
this  town  is  that  an  organization’s  strategy  is  not  that  glossy  book  laying  on  the  coffee  table  or 
the  framed  poster  in  the  main  lobby.  An  organization’s  true  strategy  is  what  comes  out  of  the 
mill  known  as  ‘resourcing’.  That  is  what  we  pay  for.  It  is  not  the  rhetoric  that  proceeds  it, 
although  there  is  a  lot  of  that.  There  is  a  lot  of  talk  about  what  we  want  to  do,  what  we  can  do, 
what  we  should  do,  and  what  the  vision  is.  However,  the  true  strategy  is  dictated  by  what  we  put 
money  against,  which  says  what  we  are  going  to  do.  So  we  can  disregard  all  of  the  dust  and 
debris  that  comes  out  of  the  budget  building  process,  the  speeches  and  all  the  posturing,  and  look 
at  the  POM  instead.  That  is  where  your  organization  is,  that  is  its  strategy,  and  that  is  what  we 
have  to  influence.  We  have  to  get  in  on  the  front  end,  because  if  we  don’t  put  into  the  POM  a 
real  assessment  of  tomorrow,  then  tomorrow  is  going  to  get  here  before  we  are  adequately 
prepared.  This  is  a  matter  of  technology  starvation,  because  if  we  get  to  tomorrow  and  there’s  no 
technology  or  only  old  technology,  then  we  are  simply  exacerbating  the  same  problem  that  we 
have  now. 

I  see  those  two  impediments  to  accepting  emerging  technology.  The  question  then  becomes: 
What  can  we  do  about  it?  A  few  minutes  ago  I  talked  about  the  cultural  state  of  an  organization, 
and  that  is  really  an  institutional  climate  for  change.  I  am  going  to  make  an  assumption  and  it  is  a 
really  big  assumption,  that  the  climate  is  favorable  and  accepting  of  change.  I  can  pretty  well 
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envision  what  I  want  in  terms  of  a  final  capability  and  I  can  also  begin  to  see  what  I  have  to  do  in 
terms  of  requirements.  The  problem  is  that  what  I  am  envisioning  is  in  the  framework  of  today.  I 
don’t  know  what  all  of  you  are  doing.  I  don’t  know  enough  about  the  technology  that  is  out  there 
that  could  help  me  fill  those  requirements  of  tomorrow.  In  the  absence  of  that  knowledge,  I  just 
grind  along  designing  requirements  based  on  what  I  know  to  exist  right  now.  The  best  I  will  get 
is  when  I  throw  these  requirements  over  the  fence  to  the  buyers  in  the  acquisition  world  and  they 
go  out  and  find  some  new  technology.  However,  frankly  what  they  will  most  likely  find  is 
technology  that  was  introduced  several  years  ago  and  is  still  being  amortized  off  some 
company’s  books. 

So  what  I  am  asking  you  for  is  concurrent  input.  Now  there  are  probably  some  lawyers  and 
contractors  who  are  starting  to  squirm  and  wiggle  around,  but  let  them  squirm  and  wiggle 
around,  we’ll  figure  them  out  later.  What  I  need  is  to  know  from  you  as  we  prepare  the 
requirements  is:  What  technology  is  under  development?  How  will  I  be  able  to  use  it?  How  can  I 
leverage  it?  Without  this  information  I  am  going  to  shoot  long  or  I  am  going  to  shoot  short  of  the 
technological  possibilities.  I  need  to  understand  what  science  is  capable  of  delivering  during  the 
time  frame  of  the  requirement.  With  that  input  I  can  put  a  whole  lot  more  rigor  into  designing  the 
requirements.  Work  with  me  in  designing  those  requirements.  Come  to  these  kinds  of  forums  and 
listen  to  the  vision,  then  be  willing  to  say:  We  have  technologies  that  could  go  in  that  direction. 

What  that  means  is  that  in  addition  to  being  who  you  are,  whether  you’re  a  scientists  or  an 
engineer  or  designer  or  wherever  your  role  in  this  business,  you  have  to  also  become  a  marketer. 
This  means  that  you  have  to  be  at  the  trade  show.  You  have  to  be  doing  the  show-and-tell.  You 
have  to  patiently  show  us  what  this  technology  or  science  is  that  you  are  working  on.  Now,  don’t 
misconstrue  that  to  mean  that  I  don’t  want  to  buy  your  product.  I  want  you  to  focus  on  my 
requirements  and  not  your  product.  That  is  a  major  change.  People  like  me  tend  to  focus  on 
products.  I  want  you  to  patiently  listen  to  my  vision,  give  me  some  realistic  technological 
boundaries,  help  keep  me  aimed  at  success  and  stay  on  target  with  what  is  possible.  Let’s  work 
together  as  a  team. 

The  next  piece  of  this  is  the  organizational  commitment.  This  is  much  more  difficult,  although  it 
is  simply  called  resourcing.  In  today’s  environment  resourcing  is  being  tied  very  directly  and 
precisely  to  analysis.  As  the  technology  becomes  available,  we  need  to  understand  the 
ramifications  and  implications  of  that  technology.  This  is  very  important.  If  you  have  a  new 
technology  and  you  can’t  tell  me  what  ramifications  come  with  it,  then  we  are  already  way 
behind  the  eight-ball,  because  we  will  be  asked  to  justify  our  acquisition  plans.  I  also  need  to 
know  the  ramifications  of  not  accepting  the  technology.  For  example,  there  may  be  technology 
out  there  that  you  know  that  the  Air  Force  has  already  decided  to  move  into.  I  am  in  the  Marine 
Corps  and  I  may  discover  this  too  late  in  the  process.  I  need  you  to  tell  me  ahead  of  time  that  the 
Air  Force  has  made  some  decisions.  Does  that  make  you  a  kind  of  extension  to  my  staff?  Maybe 
it  does. 

In  terms  of  ‘resourcing’,  when  a  new  product  comes  in  I  would  also  like  to  see  the  amortization 
of  that  product.  Are  there  going  to  be  some  related  savings?  Perhaps  I  no  longer  need  three 
people  or  this  building  or  this  other  technology  and  I  can  take  those  off  the  books.  This  is  very 


32 


important,  because  I  hear  over  and  over  again:  “We  can’t  afford  it,  it’s  just  too  expensive.”  I 
need  to  know  when  I  am  going  to  receive  a  return  on  my  investment. 

Now  why  am  I  asking  you  to  do  this?  Please  think  about  this  for  just  a  second.  I  don’t  want  to 
demean  any  of  the  Marines  in  this  audience.  We  have  some  very  bright  guys  in  here.  You  are 
very  smart,  you  have  gotten  some  advanced  degrees,  and  you  do  a  wonderful  job.  However,  you 
truly  are  the  exceptions.  You  are  the  scientists,  engineers  and  designers  in  this  world.  I  want  you 
to  stop  and  think  for  a  moment  about  our  Marine  Corps,  which  is  a  very  simple  organization.  The 
Marine  Corps  is  not  at  all  ‘high  tech’.  We  don’t  recruit  from  MIT,  we  probably  have  very  few 
Marines  who  come  from  fair  schools,  and  we  don’t  recruit  from  monasteries  for  sure.  If  you  look 
at  that  population  then  you  have  to  agree  that  they  are  not  going  to  do  this  analysis.  I  mean, 
higher  mathematics  to  a  Marine  means  “...  add  100  and  fire  for  effect”.  We  need  some  help.  I 
see  some  Marine  faces  in  here  who  I  know  are  very  competent,  but  for  the  most  part  most  of  us 
that  get  assigned  to  these  tasks  have  a  tough  time  dealing  with  the  analysis  part.  Very  few  truly 
understand  what  life  cycle  costs  are  all  about.  However,  industry  has  a  good  grip  on  answers  to 
questions  such  as:  What  does  it  cost  for  me  to  make  do  with  what  I  have  now?  What  will  it  cost 
me  to  do  with  what  you  propose?  It  is  a  simple  comparison,  but  essential  for  our  acquisition 
process. 

So,  now  I  have  given  you  two  solutions.  I  have  said  that  if  you  will  help  me  design  the 
requirements  and  if  you  will  help  me  with  the  analysis  to  present  the  case,  then  we  can  better 
accept  the  emerging  technology.  I  would  like  to  give  you  an  example  based  on  a  vision  for  a 
command  and  control  (C2)  capability  that  leverages  the  advantages  of  intelligent  agent 
technology.  I  am  going  to  place  this  in  the  context  of  a  very  fluid,  dynamic  and  widely  dispersed 
battlefield,  where  information  is  abundant  but  not  coalesced.  Not  unlike  a  blind  man  riding  a 
motorcycle  in  New  York  City  traffic  and  going  very  fast.  The  motorcyclist  has  all  kinds  of 
sensory  input  coming  in,  but  doesn’t  really  have  a  clue  that  he  is  about  to  hit  a  bus.  In  many 
respects  that  is  what  is  happening  to  us  in  this  very  dynamic  environment.  We  need  all  that  data 
to  come  in  and  to  be  somehow  related.  We  need  all  of  the  databases  that  are  out  there  to  work 
with  each  other  and  we  need  access  to  them.  However,  that  does  not  mean  that  we  are  going  to 
redesign  those  databases  or  connect  the  files,  or  better  still  design  and  implement  millions  and 
millions  of  dollars  worth  of  translators.  Recently  a  company  briefed  us  and  said  that  to  pull 
together  fewer  than  two  dozen  very  complex  systems  would  take  about  200  million  lines  of  code. 
They  had  to  scrape  me  off  the  deck;  -  200  million  lines  of  code  at  an  estimated  cost  of  $10,000  to 
$15,000  dollars  per  year  per  line  to  maintain?  I  am  surprised  that  they  had  the  courage  to  even 
tell  me  about  such  a  software  solution.  I  know  that  those  databases  are  important  and  that  we 
have  to  have  access  to  them,  but  let’s  not  try  to  pull  them  together  with  200  million  lines  of  code. 
What  we  need  is  data  in  context  so  that  software  agents  can  automatically  reason  about  the  data. 
This  would  give  us  an  incredibly  fast  staff  of  agents  that  can  find  us  the  right  information  at  the 
right  time.  Then  the  same  or  other  agents  with  different  expertise  and  reasoning  capabilities  can 
quickly  make  some  reasoned  judgments  and  recommendations,  in  collaboration  with  each  other 
and  the  human  decision  makers. 

Let  me  tell  you  a  little  story.  It’s  time  for  a  short  break,  in  any  case.  I  ride  the  train  every 
morning,  because  I  hate  traffic  and  I  have  no  patience  so  it  is  best  if  I  sit  on  the  train  and  protect 
the  public  from  my  terrible  driving.  So  one  day  a  priest  is  sitting  opposite  me  on  the  train.  A  little 
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disheveled,  kind  of  nasty,  vile  rodent  of  a  human  being  sits  down  beside  him.  This  little  rodent 
digs  out  his  newspaper  and  he  starts  thumbing  through  it  probably  just  pretending  to  read.  He 
starts  a  conversation  with  the  priest  and  says:  “Father,  what  causes  arthritis?”  The  priest  hesitates 
to  respond,  thinking  that  he  really  does  not  want  to  talk  to  this  guy  at  all.  He  is  disgusted  by  his 
apparent  condition.  But  then  he  decides  to  teach  the  man  a  lesson.  He  replies:  “Arthritis  is  caused 
by  living  a  life  of  bad  habits...  booze,  loose  women,  late  hours...  no  job,  no  bath.  The  little  man 
simply  says  “hmm,  oh.”  A  few  minutes  pass  and  the  priest  starts  to  feel  really  guilty  about  his 
reply.  He  thinks,  I’m  a  priest  I  shouldn’t  be  like  that  and,  in  any  case,  I  kind  of  stretched  the 
truth.  God  would  not  have  liked  my  response.  So,  he  turns  to  the  man  and  says:  “Please  forgive 
me  for  that  response,  that  was  very  cruel.  How  long  have  you  had  arthritis  my  son?”  The  vile 
little  man  folds  his  paper  and  says:  “No  I  don’t  have  it.  I  was  just  reading  here  that  the  Pope 
does.” 

You  always  have  to  have  a  context.  I  can  envision  a  battlefield  right  now.  It  is  crystal  clear  in  my 
mind.  As  a  commander  I  can  view  information  that  is  tailored  for  me.  I  can  tailor  it  from  a 
handheld  device  to  a  multi-screen  theater.  The  system  knows  my  personal  profile  and  my 
personal  preferences.  I  know  that  I’ll  want  my  weather  radar  showing,  so  I  tune  it  up  for  myself. 
When  my  Executive  Officer  comes  in  and  sits  down  at  the  terminal,  he  just  hits  his  button  and 
the  system  is  instantly  tailored  for  him.  I  want  to  be  able  to  adjust  those  thresholds  that  I  talked 
about  earlier.  I  want  to  be  able  to  tell  that  machine  just  what  I  tell  my  Operations  Officer,  or  the 
Watch  Officer.  Before  I  head  back  to  get  some  sleep,  I  will  tell  him  to  wake  me  up  for  only  five 
things.  All  commanders  need  this  capability.  I  want  the  system  to  be  able  to  do  that  and  I  want 
the  system  to  know  that  it  can  take  action  with  my  blessing  on  certain  things.  I  want  the  system 
to  give  me  recommendations  and  I  want  to  be  able  to  authorize  the  system  to  take  action,  in  the 
same  way  that  I  as  a  commander  would  authorize  the  Watch  Officer  to  do  certain  things.  What 
I’m  saying  is  that  the  system  has  to  be  very  tailorable.  I  want  new  options  for  decisions  that  are 
based  on  the  dynamics  of  the  battlefield  such  as  the  weather,  the  enemy  situation,  the  operational 
successes  or  failures  that  are  going  on  hour  by  hour,  logistics,  strengths,  or  potential  weaknesses 
that  I  cannot  quickly  detect  because  of  all  the  information  that  is  coming  to  me.  For  example,  a 
convoy  has  been  dispatched  after  several  hours  of  preparation  to  get  it  loaded,  get  everybody 
briefed  up,  get  the  overhead  secured,  arrange  for  the  helicopter  escort,  and  coordinate  everything 
to  ensure  the  safety  of  the  convoy.  It  is  on  the  road  and  some  new  information  comes  in 
regarding  significant  weather  changes  or  enemy  situations  that  could  impede  the  mission.  I  am 
sitting  in  a  Command  Post  (CP)  right  now  and  the  system  allows  me  to  quickly  assess  the 
situation  and  reroute  the  convoy.  Consider  the  opportunity  costs  of  simply  rerouting  the  convoy 
safely  around  the  problem  area.  What  are  the  implications  on  delivery  times?  What  are  the 
implications  on  equipment  matching.  The  new  route  may  not  be  able  to  handle  that  size  truck. 
There  may  be  a  really  important  trailer  load  10  miles  up  along  the  original  route  that  is  waiting 
for  a  tractor  in  this  convoy.  I  cannot  think  of  all  those  things  on  the  fly,  there  is  too  much  else 
going  on.  Therefore,  I  want  the  system  to  do  those  kinds  of  things.  That  is  what  I  mean  by 
dynamic  decision  making. 

I  want  a  user-interface  screen  that  offers  the  capability  to  be  entirely  collaborative,  at  the  tactical 
level,  at  the  operational  level,  and  at  the  strategic  level.  I  want  to  be  able  to  go  from  tactical  to 
operational  at  the  strategic  level,  to  operational  to  tactical  between  the  services.  I  want  the  levels 
of  staff  and  command  authority  to  be  delegated  by  me  according  to  my  personal  style.  Let’s  go 
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back  to  for  a  moment  to  the  weather  example.  You  know  we  have  meteorologists  and  equipment 
with  us  to  provide  us  with  very  local  weather  information.  We  can  also  get  regional  and  global 
forecasts,  so  we  do  have  access  to  a  fair  bit  of  weather  information.  However,  that  is  not  the 
same  as  having  a  system  that  is  continuously  looking  at  all  of  the  meteorological  data,  including 
the  two-week  global  prediction  of  sand  storms.  Such  a  system  can  very  quickly  tie  several  factors 
together,  access  a  regional  map,  and  warn  me  that  the  wind  is  really  moving  to  the  north  by  a 
long  shot  even  though  my  local  data  suggests  that  the  dust  storm  is  not  even  close  to  us.  All  of 
this  has  a  significant  impact  on  my  operational  plans  for  the  next  24  hours  and  I  can  do  much  of 
that  now  with  my  weather  reports.  What  I  cannot  do  is  to  determine  the  implications  on  my 
operations  three  days  from  now.  Also,  I  cannot  predict  the  implications  if  I  decide  to  launch  right 
now.  What  does  that  do  to  my  logistics  considerations?  Those  are  very  difficult  to  plan  if  you 
speed  up  that  much.  So,  I  want  the  system  to  collect  the  current  conditions,  the  enemy  situation, 
the  weather,  and  many  other  pertinent  factors.  Then  I  want  the  system  to  reason  about  all  of  this 
information  on  a  continuous  basis  and  give  me  conclusions  and  recommendations. 

What  if  current  operations  change?  This  happens  all  the  time.  We  may  have  a  success  that  needs 
to  be  exploited  or  a  failure  that  needs  to  be  corrected.  Many  alternatives  have  to  be  evaluated 
quickly  and  countless  decisions  have  to  be  made.  It  goes  beyond  the  combat  operations  center  to 
all  of  the  support  folks  and  their  decisions.  This  is  where  it  becomes  encumbered  and  difficult. 
The  agents  in  my  hypothetical  system  may  come  back  with  the  recommendation  to  slow  down 
the  convoy  to  10  miles  an  hour  so  that  we  don’t  bunch  up.  The  system  can  do  that  for  us  after  it 
has  reasoned  on  variables  such  as  the  weather  and  the  road  conditions.  A  success  in  the 
operational  scene  can  bring  another  re-supply  opportunity.  For  example,  we  have  had  a  success 
on  the  left  flank.  The  system  can  quickly  look  at  the  variables  and  say  that  we  could  re-supply 
right  now,  to  avoid  a  weather  that  is  coming  our  way.  In  other  words,  the  system  alerts  the 
commander  to  a  window  of  opportunity  that  is  more  than  likely  to  have  been  missed  under  the 
deluge  of  data. 

Now,  if  this  vision  of  the  C2  world  does  not  challenge  you  or  make  you  think  a  little  then  let  me 
know,  because  I  can  dream  some  more  and  I  am  more  than  willing  to  do  so.  If  what  I  have 
thought  of  is  not  acceptable  to  the  user,  then  you  and  I  have  to  work  together  to  help  change  the 
way  that  the  user  thinks  about  this.  It  can’t  be  just  speed  and  a  prettier  display  on  the  screen.  That 
wraps  up  what  I  wanted  to  share  with  you  this  morning.  Thank  you  for  your  patient  attention  and 
for  the  opportunity  to  present  my  vision  to  you.  I  believe  there  is  time  for  a  few  questions. 

Question:  In  addressing  the  issue  of  the  culture  change,  it  occurs  to  me  that  one  of  the  biggest 
impediments  is  going  to  be  the  testing  community  who  have  to  be  able  to  answer  satisfactorily 
for  the  operational  commanders ...  whether  or  not  garbage  in  equals  truth  out  or  garbage  in 
equals  truthful  garbage  out...  or  we  have  truth  in  and  truth  out,  and  that’s  a  significant  issue  in 
the  Hal  counterculture.  Are  you  making  any  inroads  on  the  testing  community  or  is  that  still  an 
area  that  needs  to  be  cultivated? 

Like  all  of  them,  that  is  an  area  that  desperately  needs  to  be  cultivated.  In  fact  that  was  one  of  the 
issues  that  General  Mattis  brought  up  to  me  when  he  talked  about  the  reliability  of  computer- 
based  systems.  I  was  actually  in  Iraq  with  him  when  he  told  me  this  and  so  he  was  still  pretty 
emotional  about  it.  He  said  what  you’re  talking  about  here  is  intriguing,  but  I  have  no  confidence 
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that  we’re  not  putting  garbage  in  and  that  I  am  not  going  to  get  garbage  out.  Then  I  am  going  to 
make  decisions  on  Marines’  lives  based  on  such  information.  We  have  to  make  some 
assumptions  that  the  data  that’s  coming  in  is  correct.  Do  we  have  any  pilots  in  here,  but  you  can’t 
fly  an  airplane  if  you  don’t  have  some  trust  that  the  data  that’s  coming  in  is  correct.  I  think  we 
can  make  people  like  General  Mattis  and  the  testing  community  more  comfortable  with  those 
assumptions  if  we  put  a  mechanism  in  there  that  occasionally  looks  at  the  data  and  tells  us  that  it 
is  within  some  kind  of  zone  of  reliability.  If  you  have  a  scared  corporal  out  there  and  you  ask 
him  to  count  the  number  of  tanks  and  he  sticks  his  head  over  the  wall  as  the  rounds  are  coming  at 
him,  then  he  is  going  to  come  back  and  say  “...  a  bunch”.  That  is  not  real  precise  data  to  work 
from  if  you  are  doing  precision  targeting. 

Question:  My  basic  question  goes  the  other  way.  The  Marine  Corps  is  working  on  how  to  use 
the  AAAV.  How  are  your  dreams  or  requirements  getting  into  the  AAA  V  and  into  the 
expeditionary  force? 

Well,  as  far  as  the  AAAV  is  concerned,  those  who  know  me  know  that  is  probably  a  bad 
example.  What  we  are  looking  at  is  autonomic  logistics.  One  of  the  difficulties  we  havve  had 
with  that  are  feeds.  There  is  just  too  much  information  to  get  through  the  pipes.  I  was  down  at 
Oakridge  and  they  showed  me  this  phenomenal  technology.  It  takes  away  the  requirement  to 
have  a  constant  transmission  of  data  from  sensors.  Instead  it  measures  electric  pulses  in  a 
predictive  manner.  This  is  what  the  Air  Force  uses  now.  You  place  these  clips  on  different  parts 
of  the  airplane  at  incremental  points  in  the  life  of  the  aircraft,  for  example  after  every  100  hours 
of  flight  or  something  like  that.  Based  on  the  measurement  and  interpretation  of  electric  pulses 
the  software  can  make  some  determination  that  there  is  a  bad  bearing  or  that  something  is  not 
running  up  to  speed.  What  is  important  is  that  you  don’t  need  to  transmit  data  constantly.  You 
just  need  to  take  a  look  at  the  data  that  comes  in  during  periodic  checks  to  be  able  to  predict  a 
future  failure.  I  would  suggest  that  as  far  as  the  AAAV  is  concerned,  we  want  to  go  in  that 
direction. 

In  respect  to  the  expeditionary  force,  we  are  dealing  with  something  quite  different.  The 
dispersed  battlefield  is  not  really  a  new  idea.  We  probably  used  dispersed  operations 
unintentionally  during  World  War  II  and  we  certainly  used  them  intentionally  in  Vietnam. 
However,  we  did  not  have  all  of  the  capabilities  that  we  have  right  now.  A  dispersed  battlefield 
in  the  future  means  that  we  are  going  to  have  one  squad  20  miles  out  here,  another  squad  20 
miles  out  there,  and  a  platoon  40  miles  out  over  here.  We  have  to  know  what  they  are  going  to  do 
today,  tomorrow  and  the  day  after,  and  what  their  requirements  are  going  to  be  and  how  we  can 
get  them  back  together  again.  Right  now  all  we  really  have  is  a  radio,  and  that  is  not  enough.  We 
also  need  to  have  some  decision-support. 

Thank  you  very  much. 
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Information  Integration  and  Decision 

A  Strategic  Approach  for  Interoperability 


Mr.  Don  Diggs 

Director  C2  Policy,  OASD(NII) 


In  the  read  ahead  provided  on  this  conference,  it  was  noted  that  the  “theme”  was  interoperability. 
Topics  identified  included:  Homeland  Security,  GIG  architecture,  multilateral  and  coalition 
interoperability,  taxonomies  and  ontologies,  and  government  plans  and  initiatives.  While  I’m 
not  an  expert  on  any  one  of  these  areas,  I  hope  in  the  following  minutes  I  can  provide  an 
overarching  context  to  the  approach  DoD  is  taking  toward  interoperability  as  well  as  provide  an 
example  of  how  we  may  want  to  “field”  capabilities  in  the  future. 

Whenever  I  hear  the  words  ontology  and  taxonomy  I  think  of  the  word  Secure.  It  is  an  old  joke 
but  it’s  said  that  one  reason  the  Services  have  trouble  operating  jointly  is  that  they  don't  speak 
the  same  language.  For  example,  if  you  told  Navy  personnel  to  "secure  a  building,"  they  would 
turn  off  the  lights  and  lock  the  doors.  Army  personnel  would  occupy  the  building  so  no  one 
could  enter.  Marines  would  assault  the  building,  capture  it,  and  defend  it  with  suppressive  fire 
and  close  combat.  The  Air  Force,  on  the  other  hand,  would  take  out  a  three-year  lease  with  an 
option  to  buy. 

Now  if  you  think  of  the  word  “tank”  in  the  same  context,  it  becomes  apparent  that  we  have  much 
to  do  in  breaking  down  the  language  barriers  that  will  allow  net-centricity.  We  need  to  move 
toward  net-centricity  with  an  enterprise  architecture.  Don’t  even  ask  me  to  define  what 
architecture  is,  but  it’s  clear  that  as  we  charge  ahead,  and  if  we  are  to  be  interoperable,  we  need 
to  work  on  the  basics. 

I  am  entitling  this  presentation  Information  Integration  and  Decision,  and  the  reason  I'm  doing 
that  is  because  we're  wrestling  with  the  notion  of  domains  today  in  the  Department  of  Defense. . . 
one  of  the  domains  is  the  C2  domain.  There  are  a  lot  of  people  that  claim  ownership  of  that  C2 
domain;  in  fact  the  real  owner  of  C2  is  the  warfighter.  OSD  Nil  (Networks  and  Information 
Integration)  is  the  Principal  Staff  Assistant  for  C2.  That  doesn't  mean  Nil  is  doing  C2. . .  we  are 
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not  doing  the  functions  of  C2  nor  do  we  specify  what  those  functions  are,  BUT  we  need  to  be 
able  to  provide  an  integrated  information  capability  much  along  the  line  that  General  Lott 
described.  We  need  to  support  decision-making  with  C2  services  and  applications  tools. 

Network  Connectivity  and  Services 


Network  Connectivity  and  Services 
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I  am  going  to  talk  a  little  bit  about  data  and  the  importance  of  data.  It  is  not  that  there  is  too 
much  data  out  there,  but  there  are  two  problems:  we  don't  know  how  to  handle  the  data 
appropriately  and  we  don't  have  a  common  data  structure.  I  will  talk  more  to  this,  but  a  good 
example  is  UAVs  ...  we  fly  UAVs  over  in  Afghanistan  all  the  time,  usually  they  are  targeted  on  a 
specific  area  on  a  specific  day  on  a  specific  mission.  The  problem  is  that  they  are  always 
filming,  always  taking  pictures  on  their  way  in  and  on  their  way  out.  It  is  very  likely  that  these 
UAVs  are  going  over  a  target  rich  environment  for  somebody  who  doesn't  even  know  the  UAVs 
are  flying.  The  information  the  UAVs  see  may  fulfill  a  future  need  for  someone  who  doesn't 
even  know  that  he  needs  the  information  on  that  area  until  several  days  later.  How  do  we 
capture  that  data,  but  still  make  sure  it  does  not  overload  the  system  and  get  it  to  the  warfighters 
when  they  need  it? 

Frank  Coyle  has  a  book  out  I  recommend  reading  if  you  haven’t  already.  In  his  book  “XML, 
Web  Services,  and  the  Data  Revolution,”  he  notes  how  the  Web  and  data  description  technology 
known  as  XML  have  initiated  fundamental  changes  to  networks  by  shifting  the  focus  from 
tightly  coupled  computing  environments  to  loosely  coupled  networks  centered  around  the  Web 
and  XML.  The  effect,  he  notes,  has  spawned  three  revolutions. 

•  The  first,  the  data  revolution,  is  the  story  of  XML  and  its  impact  on  how  to  represent 
data. 

•  The  second  is  about  software  architectures  and  the  move  to  loosely  coupled  distributed 
systems. 
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•  The  third,  the  software  revolution,  involves  a  changing  model  of  software  construction  - 
software  based  on  simplicity  and  modularity,  rather  than  software  that  “does  it  all”. 

This  Internet  Model  drives  the  underlying  technology  and  processes  for  the  DoD  Net-Centric 
enterprise.  Further,  it  requires  interoperability  at  the  information  level  to  support  timely 
execution  of  operations  and  compels  a  shift  from  point-to-point  to  a  many-to-many  exchange  of 
data. . .  many  users  and  applications  leveraging  the  same  data.  What’s  important  is  how  we  share 
data  across  the  enterprise  so  that  the  warfighters  who  need  the  information  can  access  it  and  use 
it  in  ways  unique  to  their  needs. 

The  point  I  want  to  make  on  this  chart  is  that  our  approach  forward  to  net  centricity  must  reorient 
toward  a  market  driven  approach  rather  than  from  the  top  down.  And  more  importantly,  our 
acquisition  processes  that  here-to-fore  have  been  focused  on  the  military  departments  and 
programmatics  needs  to  be  more  adaptable  to  a  more  dynamic  environment. 

The  “Set  of  Interconnections” 
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Net-centricity  is  the  realization  of  a  networked  environment,  including 
infrastructure,  systems,  processes,  and  people,  that  enables  a  completely 
different  approach  to  warfighting  and  business  operations 


Another  consideration  is  how  we  ensure  the  strategic  goals  specified  in  the  last  Quadrennial 
Defense  Review,  ASSURE,  DISSUADE,  DEFEAT,  and  DEFEND,  shown  around  the  outside 
four  comers,  can  be  achieved  in  a  net-centric  environment. 

Certainly,  those  goals  must  be  supported  by  a  strong  command  and  control  capability  represented 
by  a  set  of  processes  as  shown  in  the  boxes  around  the  globe.  Those  processes  are  supported  by 
functions  and  capabilities.  The  question  is  how  we  map  functions  and  capabilities  to  services 
and  applications  in  an  enterprise  fashion  that  resides  on  a  network  and  is  supported  by  services 
and  applications.  That  is  the  difficulty.  How  do  we  map  functions  to  capabilities  in  what  today 
is  largely  programs  fielded  in  stovepipes.  Building  the  GIG  architecture  is  the  first  step. 
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Key  Net-Centric  Initiatives  Roadmap 
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I  promise  not  to  linger  on  this  slide,  but  it  does  address  the  DoD  goals  in  implementing  the  GIG, 
which  are  threefold: 

•  Goal  1  is  to  build  a  trusted,  dependable  network, 

•  Goal  2  is  to  populate  the  network  with  accessible  and  usable  data, 

•  Goal  3  is  to  protect  the  network  from  exploitation. 

The  graphic  provides  insight  into  Department’s  efforts  to  support  these  goals.  I  won’t  go  into 
detail  -  that  would  be  a  whole  other  brief  -  but  as  indicated  in  the  programs  and  initiatives  on  the 
left...  the  Joint  Tactical  Radio  System,  the  GIG  Bandwidth  Expansion  effort  and  the 
Transformational  Communications  Architecture  Satellite  Communications  Systems...  will  allow 
the  Department  to  reduce  network  bandwidth  constraints.  Net-Centric  Services  and  Information 
Assurance  efforts  will  allow  employment  of  trusted  services  to  users  of  the  GIG.  Lastly,  our 
Horizontal  Fusion  Portfolio  efforts  will  develop  Net-Centric  tools  to  enable  smart  pull  and  fusion 
of  data  by  GIG  users. 
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GIG  -  Service  Oriented  Architecture 
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The  traditional  approach  to  interoperability  has  been  the  “system-of-systems”  approach.  First, 
true  interoperability  can  only  be  achieved  through  data  management,  with  the  focus  on  the 
visibility  and  accessibility  of  data  rather  than  just  standardization  of  the  data.  Improving  the 
flexibility  in  data  exchange  means  interoperability  between  systems  can  be  achieved  without 
requiring  predefined  and  node-to-node  mapping  of  interfaces.  Second,  data  becomes  actionable 
information  through  applications  and  services.  The  services  available  on  the  network  are  either 
enterprise  services  (e.g.,  NCES)  or  developed  and  offered  at  the  community  level.  The 
Enterprise  Services  provide  basic  computing  capabilities  to  the  Enterprise,  for  example, 
providing  reliable  identification  and  authorization  services  to  assure  the  security  of  the  data. 
Additionally,  users  and  applications  through  enterprise  services  will  be  able  to  exploit  easy  to 
use  search  tools  and  software  agents  that  allow  them  to  search  metadata  catalogues  and  “pull” 
data  from  across  the  various  communities  and  the  Enterprise.  And  third,  applications  and 
services  need  to  be  supported  through  an  architecture.  The  increased  use  of  networked  data 
capabilities  requires  a  ubiquitous,  high-speed,  dependable  communications  infrastructure. 
Accordingly,  the  enterprise  services  will  be  deployed  on  the  GIG  and  will  leverage  the  expanded 
bandwidth  and  network  availability  provided  by  TCS,  JTRS,  and  GIG-BE  activities. 


Finally,  organization  and  maintenance  of  data  is  the  responsibility  of  Communities  of  Interest, 
or  COIs.  COIs  promote  data  posting,  establishing  “shared”  space,  and  creating  meta-data 
catalogs.  Data  can  be  exposed  within  the  COI  or  across  the  Enterprise  by  having  users  and 
applications  advertise  their  data  assets  by  cataloging  the  associated  metadata  or  the  descriptive 
information  about  the  meaning  of  data.  Catalogues,  which  describe  the  data  assets  are  available, 
are  made  visible  and  accessible  for  users  and  applications  to  search  and  pull  data  as  needed. 
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The  goal  is  increasing  the  data  available  to  communities,  or  the  enterprise,  and  ensuring  that  data 
is  usable  by  both  anticipated  and  unanticipated  users  and  applications.  Making  the  data  visible, 
accessible,  understandable,  and  trusted  is  the  key  to  interoperability  between  systems. 


New  Paradigm  Challenges 


New  Paradigm  Challenges 


•  Publish  and  Access 

■  How,  where  and  what  do  data  resources  publish? 

■  How  do  users  find  and  access  resources? 

■  How  is  data  product  or  service  delivery  achieved? 

•  Context:  Global  Information  Grid  (GIG) 

■  Massively  networked  environment 

■  Many  complex  interconnections 

■  Numerous,  frequently  changing  data  resources 

■  Dynamic  network  architectures  (e.g.,  crisis-specific) 


This  enterprise  environment  provides  opportunities  and  challenges.  For  example,  how  and 
where  do  we  publish  data  resources  and  then  how  do  users  access  those  resources?  And,  how  do 
we  assure  delivery  of  data  resources?  Who  is  responsible  for  maintaining  the  data? 

The  GIG  is  a  massively  networked  environment  with  many  complex  interconnections.  It  is 
highly  dynamic.  How  we  model  the  environment,  understand  domains,  and  operate  COIs  within 
the  enterprise,  for  now,  creates  more  questions  than  we  have  answers. 

C2  in  a  Service  Oriented  Architecture 


Service  Oriented  Architecture 


C2  Legacy  Programs 
wrapped  to  leverage 
past  investments 


42 


Nil  is  working  with  the  Joint  Staff  and  the  various  combatant  commanders  to  place  context 
toward  this  challenge.  For  example,  if  you  were  to  view  one  of  the  Joint  Staff  domains,  in  this 
case  C2,  against  the  Mission  Capability  Packages  or  MCPs,  in  the  context  of  a  SOA,  it  might 
look  like  this. 

DoD  is  just  beginning  to  look  at  the  decomposition  of  C2  services  and  applications  that  are 
available  within  programs  of  record  to  support  the  MCPs  and  to  define  how  COIs  support  this 
effort. 


What  is  Required 


What  is  Required 


*  Develop  i  articulate  DoD  C2  policies  for  integrated,  net-centric  C2 
capabilities 

■  Drive  changes  to  doctrine,  concepts,  and  processes 

■  Explore  new  implementation  strategies 

*  Leverage  network  connectivity  and  web  services  to  enhance 
information  integration  and  decision-support  to  the  warfighter 

■  Achieve  a  seamless  and  ubiquitous  command  structure  (national  through 
tactical) 

■  Ensure  data  is  visible,  available  and  usable  which  promotes  interoperability 
through  standardization  of  data  elements 

*  Define  a  services  oriented  architecture  (SOA)  that  allows  for 
“interconnections”  between  the  President,  senior  leaders,  and 
warfighters  that  will  meet  critical  G2  functions  and  decisions 

■  Enhance  senior  decision-maker  ability  to  dynamically  collaborate 

■  Improve  Combatant  Commanders  execution  of  supported  and  supporting 
roles  -  globally  and  regionally 

■  Enable  agile  C2  to  the  warfighter 

So  what  is  required . 

The  DoD- wide  C2  policy  we  currently  have  on  the  books  is  from  1972  and  is  titled  Worldwide 
Military  Command  and  Control  System  or  WWMCCS.  This  policy  has  not  been  updated  and 
needs  to  be. 

We  need  to  drive  changes  to  doctrine,  concepts  and  processes  that  address  the  things  General 
Lott  was  talking  about...  things  that  he  needs  out  in  the  field.  These  concepts  are  not  going  to 
happen  without  looking  at  new  ways  of  fielding  capabilities.  It  is  very  difficult  to  meet  the  needs 
of  what  the  General  wants  the  way  our  acquisition  system  is  structured  today.  We  need  to 
explore  new  implementation  strategies  that  leverage  network  and  web-based  services  and  allow 
broader  access  and  use  of  authoritative  data.  There  are  ways  within  the  construct  of  what  we 
have  today  to  implement  some  of  the  services  and  applications  in  a  Service  Oriented 
Architecture  in  which  connectivity  and  web  services  can  enhance  information  integration  and 
decision  support. 
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Again,  we  need  to  ensure  that  the  data  is  visible  available  and  usable  and,  I  keep  going  back  to 
that  because  I  think  it  is  one  of  the  basics  that  we  haven't  gotten  right.  People  are  still  going  out 
and  fielding  services  and  applications  program  by  program  with  the  dissimilar  ontologies  and 
taxonomies  and  with  data  that  can't  be  used  by  other  programs.  A  good  example  is  the 
Combatant  Commanders  Integrated  Command  and  Control  System  (CCIC2S).  It  provides 
intelligence,  indications  and  warning,  and  attack  assessment  for  NORAD.  A  lot  of  good  data 
resides  in  CCIC2S  that  is  used  by  applications  and  services  specific  to  NORAD  for  missile 
warning,  space  operations  and  the  like.  Unfortunately,  as  we  move  forward  with  missile  defense 
some  of  the  data  MDA  needs,  particularly  at  the  sensor  level,  resides  in  CCIC2S  which  for 
certification  reasons  cannot  currently  be  shared.  Similarly,  MDA  systems  will  generate  data  that 
CCIC2S  can  use  for  Integrated  Tactical  Warning  and  Attack  Assessment  but  can  not  directly 
access.  As  a  result  decision  makers  wind  up  with  separate  operational  pictures  for  missile 
warning  and  missile  defense  which  they  then  have  to  integrate  mentally.  This  is  a  problem  we 
can  solve  through  an  SOA  approach  to  allow  interconnections  between  the  President,  senior 
leaders  and  warfighters  and  create  user  defined  operational  pictures  that  will  dynamically  change 
how  we  operate  and  achieve  agile  command  and  control. 


DoD  Net-Centric  Transformation  for  Global  C2 
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As  we’ve  discussed  before,  DoD  is  being  driven  by  the  commercial  internet  model  that  is  ad  hoc, 
loosely  governed  and  market  driven.  This  model  is  really  what  is  pushing  net  centric  operations. 
The  question  is,  what  do  we  do  with  current  programs  of  record,  many  that  are  legacy,  but  that 
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still  have  significant  dollars,  and,  more  importantly,  authoritative  data  attached  to  them. 
Currently,  we  do  not  have  a  coordinated  path  for  how  to  take  programs  into  this  net-centric 
environment.  We  should  be  able  to  move  now  on  some  of  these  programs  to  encourage  them  to 
adopt  key  net-centric  elements  such  as  defining  domain  ontologies  and  taxonomies,  and  ensuring 
their  data  is  visible,  available,  and  usable  as  well  as  exposing  services  and  applications  to  the 
network.  Today,  we  do  not  have  a  cohesive  path  for  doing  this  -  each  program  must  map  to  the 
GIG  independently. 

C2  Gaps  &  Challenges 
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One  reason  we  need  to  move  rapidly  into  the  net-centric  environment  is  to  address  the  gaps  and 
challenges  we  have  in  C2  today.  I  don’t  think  it  is  a  surprise  that  we  have  significant  gaps  in 
Strategic,  Global  and  National  C2  capabilities.  9/1 1  exposed  many  of  these  gaps  and  this  was 
largely  a  result  of  having  fielded  programs  supporting  national-level  C2  in  a  stove -piped  fashion. 

In  addition  to  this  dynamic  security  environment  there  is  new  high-level  guidance  such  as  the 
Nuclear  Posture  Review,  the  Unified  Command  Plan,  and  other  Presidential  directives  that 
require  DoD  have  enhanced  Command  and  Control  capabilities.  The  NPR  was  really  a  strategic 
posture  review  that  redefined  the  old  nuclear  TRIAD  into  a  New  TRIAD  consisting  of  nuclear 
and  non-nuclear  forces,  active  and  passive  defenses  and  a  responsive  infrastructure  to  achieve  the 
nation’s  strategic  goals.  To  achieve  the  resulting  strategic  capabilities  and  accomplish  these  new 
missions  means  that  DoD  must  take  a  new  approach  toward  C2,  intelligence  and  planning 
capabilities. 
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Again,  the  question  is,  how  do  we  transform  legacy  C2  programs,  some  where  we  have  a  very 
large  investment,  and  expose  their  data  and  services  to  the  network. 

A  Portfolio  Approach 


A  Portfolio.  Approach 


Define  global  C2  capabilities 
required  for  strategic  reference 
mission(s)  &  scenarios 

Establish  a  ‘portfolio’  of  services 
from  existing  C2  programs  of  record 
that  fulfill  defined  capabilities 
4  Shifts  focus  from  programs/ 
platforms  to  capabilities 
4  Reduces  operational,  future,  force 
management  and  institutional  risks 
of  Global  C2  implementation 

Leverage  Net-Centric  initiatives  (e.g. 
GIG,  NCES) 

Capture  portfolio  lessons  into 
guidance,  policy,  doctrine,  standards 
for  broader  domain  application 

Requires  strong  warfighter  support 
to  advocate  and  support  portfolio 
efforts 


jf/JI  bp,»: 

Ui ‘ 

■■■ 

Policy, . 
Standard^, 


One  approach  is  to  use  portfolio  management.  A  portfolio  approach  may  be  that  we  define  the 
global  C2  capabilities  required  for  strategic  reference  mission(s)  and  scenarios.  Then,  we  can 
establish  a  ‘portfolio’  of  services  and  applications  from  existing  C2  programs  of  record  that 
fulfill  our  defined  capabilities.  The  result  of  such  an  approach  is  a  shift  in  focus  from 
programs/platforms  to  capabilities  and  to  data  and  services.  By  leveraging  Net-Centric 
initiatives  (for  example  Net-Centric  Enterprise  Services)  we  should  also  be  able  to  reduce 
infrastructure  costs  to  current  programs  of  record. 

With  success,  we  can  then  capture  portfolio  lessons  into  guidance,  policy,  doctrine,  standards  for 
broader  domain  applications.  Such  an  approach  will  require  strong  warfighter  advocacy  and  will 
challenge  current  organizational  boundaries. 

I’d  like  to  walk  through  an  example  of  how,  from  capabilities,  one  might  begin  to  identify 
services  and  applications  of  importance  and  help  us  focus  on  important  data  sources. 
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Global  Information  Integration  and  Decision  for  an  ODI  Mission  Thread 


Global  Information  Integration  and 
Decision  for  an  ODI  Mission  Thread 


:  Rea  forces  Prepare  for  Missile  launch 


! 


■ 

Blue  force  law,  Situational  Awareness 


~  ~  launch  Belayed  _ _ _ 

I  “  launch  Execute  a  “  Attempt  at  2"“  launch  _ 

-t  J  1 1 — i — f* — i1  r 

I  .  I  ■  f  J  J  i  .  .I,U  .Ml  - 


eon  Planning 


18  Event 


This  looks  complicated  until  you  break  the  code....  essentially  we  are  looking  to  fill  capability 
gaps. 

The  example  here  uses  a  specific  mission  thread,  in  this  case  offensive-defensive  integration,  as  a 
way  to  define  the  capabilities  and  services  that  must  be  present  and  then  maps  the  services 
available  through  various  programs  and  initiatives  that  can  support  this  mission  thread. 

In  this  way  we  can  determine  where  programs  provide  like  or  similar  services,  showing  where  a 
“best  of  breed”  selection  can  or  should  occur  and  also  where  the  deficiencies  or  gaps  in 
capability  are. 
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Representative  GIID  Portfolio  Services 


Representative  GIID  Portfolio 

Services 


Program 

Service 

CCIC2S 

Blue  Force  Satellite  Status  and  Readiness 

Warning  Asset  (Radars  &  IR)  Status  and  Readiness 

NORAD  Air  Tracks 

Missile  Launch  Warning  (ITWAA) 

Space  Tracks 

Non-NORAD  Air  T  racks 

Missile  Warning  /  Missile  Defense  Integration 

C2BMC 

Missile  Launch  Warning  (Non-ITWAA) 

Ballistic  Missile  Operational  Plan  Data 

Ballistic  Missile  Engagement  Status  Reports 

Ballistic  Missile  Prioritized  Defended  Asset  List 

D-SIDE 

Mission  Analysis  Service 

Tasking  and  Orders  Management  Service 

FBV-C2Mod 

Text,  Table,  and  Geospatial  display  for  MARS  Portal 

ECOI 

Activate  Expedient  Communities  of  Interest 

Discover  Expedient  Communities  of  Interest 

Use  Expedient  Communities  of  Interest 

These  services  were  originally  developed  based  on  unique  system  requirements  for  two 
stovepipe  programs,  missile  warning  and  missile  defense.  These  services  can  not  effectively 
provide  an  integrated  missile  defense  picture  that  supports  both  offensive  and  defensive 
responses  to  the  same  event  unless  the  programs  are  redirected  and/or  incentivized  to  publish 
their  data  and  expose  the  identified  services  to  the  network,  and  to  each  other. 


GIID  Portfolio  Gaps 


GIID  Portfolio  Gaps 

Strategic  Objective:  Fuff-spectrum  response  to  th  wart  na tiona / missile  attack  | 
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After  filling  one  gap,  future  spirals  are  directed  toward  filling  other  gaps  that  are  part  of  the  same 
mission  thread...  as  net-centric  services  are  fielded  filling  a  gap  in  one  mission  area  will  also 
fulfill  gaps  in  other  mission  areas  resulting  in  spirals  that  cut  across  mission  threads  as  well  as 
focus  on  a  given  mission  thread. 

Prospective  follow-up  GIID  Portfolio  ODI  Mission  Service  List 


Prospective  follow-up  GIID  Portfolio 

ODI  Mission  Service  List 


CCICC3 

Biue  Fo  rce  Saleilie  Sta  tus  Read  ness 

R'G  Force  Salelde  Status  /  Read  ness 

Warning  Asset  (Radars  +  IR)  Status  & 

Read ness 

NO  RA  D  Arr  T  racks 

Satelde  FootpnntCoverage  [Qve rf iig h L) 

Enemy  Ballistc  Missite  QOB 

Enemy  Satellite  GGB 

Space  Tasking  Order 

Th  reals  to  Nato  na  1 E  pace  A  ssets 

7h  reats  to  Nal  on  a  1  La  nd  Ee  nso  rs 

Threat  from  BaBistt  Missiles  to  North 
America 

Threat  from  Ballistic  Missiles  to  Theaters 

fAssile  Launch  Warning-  (ITWAA) 

Missile  Launch  Warning  -  I'Non-ITWAAi 

GPS  NAV  Accuracy 

Space  Tracks 

Non  NO  RAD  Air  Tracks 

Missile  Wa  m  mg/Mtssib  Defense 

Integration 

IS  PAN 

NatbnalTaget  Base 

NATF  mission  data 

Urid  mission  data  (bomber,  tanker,  ICBM, 
SLBM,  Recce,  TL AM) 

Analysis: GofE,  FA,  PD.  FTP 

Theater  m&siondata 

□ 

m 

Missile  Launch  Warning  -  (Non-ITWAA) 

Ballist  c  Missile  Track  Reoons 

BM  Threatened  Assel  Reports 

BM  CAP  Data-  Red  Force 

BUDS  Weapons  CAP  Data 

BM  OPLAN  data 

BM  AD  P  data 

BM  Defense  Desgn  Data 

BM  Candidate  Targel  Nomination  Lists 

Red  BM  DOB  Update 

Blue  BMD  Asset  update 

BM  Engagement  Status  Reports 

Projected  interceptor  tracks 

BM  Priaritzed  Defended  Asset  List 

□ 

O 

E 

s 

m 

u 

Strategic  Force  Slalus  and  Location 

Strategic  Force  Read  mess 

Base  Pasture 

Text  Display  service 

Table  Display  service 

Geospalial  display  service 

Timeline  display  service 

image  display  service 

Mission  Details  Service 

Air  Tasking  Cider  Generation  {file) 

ATQ  Selected  Elements 

:Air  Control  l  Coordination  Cider 

GBnerafionJfije^ 

ACO  Selected  Elements 

[Strategy  Management  Service 

£0 

Airspace  Usage  View 

SI 

;Enemy  A  r  Order  Baltle 

EG 

N 

Enemy  Anti-Aircraft  Order  of  Battle 

^Global  Strike  Assel  Availioility/S  uilabilty 
Service 

LU 

Mission  Analysts  Service 

Q 
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Tasking  and  Order  Mgt.  Service 

6 

Execution  Mgt  Service 

5 

Identification  of  expedient  community 

£ 

ECOI  business  rules  and  rales 

[0 

Coalition  NBC  Event  Notification 

Q 

Coalition  Tracks 

£ 

Coalition  Interdiction  Candidates 

o 

■Jrj... 

Coalition  NBC  Event  BDA 

Focus  for  FY06  --  add  Integrated  Space  Operations 
Planning,  Execution  and  Display  capability 
(highlighted  items  reflect  candidate  services) 


In  this  case  the  identification  of  additional  services  and  applications  is  needed  to  address  the  gap 
in  integrated  space  situational  awareness.  The  portfolio  approach,  therefore,  allows  us  to 
gradually  evolve  net-centric  services  within  and  across  mission  areas  by  not  focusing  on 
stovepiped  programs  but  by  looking  at  how  services  and  applications  within  these  programs  can 
be  identified  to  fill  capability  gaps. 
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Challenges  to  Interoperability 


Challenges  to  Interoperability 


*  Achieving  transparency  in  mission  and  domain  governance 

*  Avoiding  the  desire  for  the  100%  solution 

■  Recognize  the  'Network"  as  a  loosely-coupled  and  dynamic  "mega-system" 

■  Less  focus  on  a  '"grand  design"  and  accept  "complexity" 

*  Optimizing  the  network  by  shifting  focus  from  individual  C2  programs  and  / 
or  missions  to  C2  capabilities  enabled  by  C2  services  I  applications. 

*  Breaking  down  the  “organizational”  boundaries  in: 

Objectives 

Management 

Funding 

The  challenges  to  achieving  net-centric  interoperability  are  many. 

The  first  is  in  the  area  of  governance.  Experience  shows  that  governance  is  required  to  set  the 
rules  that  determine  how  a  mission  area  will  function  and  define  or  develop  the  services  and  data 
needed  within  that  domain.  However,  putting  governance  in  place  for  this  new  transformational 
environment  is  difficult  to  achieve  because  it  transcends  the  organizational  rice  bowls  we  have 
had  in  place  for  some  time.  One  approach  is  to  look  at  governance  as  a  function  of  COIs  and  let 
COIs  define  services  and  data  strategies  for  the  missions  they  are  created  to  accomplish. 

A  second  challenge  is  the  natural  desire  to  find  a  100%  solution  and  having  all  the  answers  in 
hand  before  moving  forward.  We  need  to  recognize  that  the  network  is  going  to  be  a  loosely 
coupled,  dynamic  mega-system,  not  tightly  coupled  applications  and  communications  that 
provide  point  to  point  connections  as  in  the  past.  It  is  important  to  focus  less  on  the  grand  design 
of  what  we  are  building  and  accept  and  adapt  to  the  complexities  involved. 

Finally,  I  think  we  need  to  optimize  the  network  by  shifting  the  focus  from  individual  C2 
programs  and  missions  to  C2  capabilities  enabled  by  services  and  applications.  To  do  so 
requires  changes  in  the  organizational  structure  to  allow  new  ways  of  developing  service 
oriented  capabilities  and  allow  data  to  be  shared  across  traditional  organization  boundaries.  This 
applies  to  how  we  fund  programs  as  well.  In  the  future  we  need  to  think  in  terms  of  how 
programs  can  leverage  applications,  services  and  data  from  other  programs  within  the  net-centric 
environment  and  fund  only  those  applications  and  services  that  are  unique.  Funds  can  then  be 
redirected  toward  filling  capability  gaps  as  they  are  identified. 
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Summary  -  What  is  Needed 


Summary  -  What  is  needed 


•  A  cohesive  path  forward 


■  Adopt  a  Services  Oriented  Architecture  (SOA)  strategy  for 
deployment  of  capabilities 

■  Understand  interactions  that  must  be  established  to  field  an 
SOA  through  existing  DoD  processes  (JCIDS,  Acquisition, 
PPBE) 

■  Put  backbone  into  data  strategy  and  begin  the  domain  grunt 
work  -  establish  requirements,  taxonomies,  data  structures,  etc. 


•  Clear  /  unambiguous  leadership  and  strategic  direction 

■  Roles  and  responsibilities  need  to  be  defined 

■  Organizational  boundaries  need  to  be  overcome  -  objectives, 
management  and  funding 


In  summary,  what  is  required  is  a  cohesive  path  forward.  Clearly  the  Department  of  Defense  is 
moving  forward  with  the  development  of  the  network;  the  GIG.  It  remains  a  challenge  to  move 
from  a  programs  and  platforms  oriented  acquisition  approach  to  a  data  centric  approach, 
supported  by  a  services  oriented  architecture  strategy  for  deployment  of  capabilities. 

It  is  also  clear  that  while  we  need  to  work  through  existing  DoD  processes,  specifically  JCIDS, 
acquisition,  and  PPBE,  the  interactions  between  these  processes  and  fielding  net-centric 
capabilities  remain  a  challenge.  Roles  and  responsibilities  need  to  be  defined  and  organizational 
boundaries  need  to  be  overcome  in  the  area  of  management  and  funding. 

Mostly  we  need  to  begin  to  put  backbone  into  data  strategy  and  start  the  domain  grunt  work  - 
establish  requirements,  taxonomies  and  ontologies,  and  define  data  structures. 

We  need  a  path  forward. 
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Path  Forward 


Path  Forward 


*  Establish  strategic  leadership  and  a  “DoD  Enterprise  View”  for  C2 
across  global  and  regional  net-centric  infrastructures 

■  Consider  creating  a  ,:C2  Committee  of  Principals'1 

*  Manage  deployment  of  C2  capabilities  through  a  portfolio  strategy  and 
resulting  technical  architecture 

*  Pace  the  evolving  National  Security  and  Military  Strategy  (i.e.  avoid  C2 
as  a  limiting  factor)  by  driving  the  Network  to  support  C2  capabilities 
across  the  threat  spectrum 

*  Put  backbone  into  domain  initiatives  that  are  languishing 

■  Adopt  a  Services  Oriented  Architecture  (SOA)  strategy  for  deployment  of 
capabilities 

■  Support  through  existing  DoD  processes  (JCIDS,  Acquisition,  PPBE) 

■  Begin  the  domain  grunt  work  -  establish  requirements,  taxonomies,  data 
structures,  etc. 


These  are  the  things  we  need  to  do  to  achieve  true  interoperability  within  the  DoD  as  we  move 
into  the  next  budget  cycle  and  these  are  the  things  that  I  have  talked  about  as  necessary  to 
achieve  the  C2  capabilities  needed  to  support  our  leaders  and  warfighters  as  we  transform  to 
meet  future  challenges. 

DoD  Transformation 
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DoD  Transformation 


Network-centric  transformation  is  working 

*  The  information  revolution  is  transforming  our  society  and  the  way 
we  live.  It  is  transforming  the  Department  of  Defense 

*  DoD  is  leveraging  these  capabilities  to  transform  the  Department  by 
creating  interoperability  at  the  data  level  and  enabling  Network- 
Centric  operations 

*  The  benefits  of  these  changes  are  being  shown  daily  in  Iraq, 
Afghanistan,  and  elsewhere.  They  are  improving  military  capability 
and  saving  the  lives  of  our  troops  daily 


•  DoD’s  network-centric  initiatives  are  delivering  on  their  promises. 
The  pace  of  change  is  accelerating  and  will  have  an  increasing 
positive  impact  on  the  Department’s  future 


In  conclusion,  Net-Centric  transformation  is  working.  The  information  revolution  is 
transforming  our  society  and  the  way  we  live  and  DoD  is  creating  interoperability  at  the  data 
level  and  enabling  Net-Centric  operations.  The  benefits  of  these  changes  are  being  shown  daily 
in  Iraq,  Afganistan,  and  elsewhere.  They  are  improving  military  capability.  DoD’s  Net-Centric 
initiatives  are  delivering  on  their  promises  and  will  have  an  increasing  positive  impact  on  the 
Department’s  future. 

Thank  you  for  your  time.  Are  there  any  questions? 
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Coalition  Secure  Management  and  Operations  System  (COSMOS) 

A  Role-Based  Access  and  Privilege  Model  for  Coalition  WAN  Operations 

6th  Annual  Office  of  Naval  Research  Conference 
9  Sept  2004 

Col  Kevin  B.  Jordan,  USMC 
U.S.  PACOM  J63 

Kevin.B.Jordan@pacom.mil 

Mike  Laurine 

Defense  Information  Systems  Agency  (APC-32) 
Laurinem@aits-jpo.disa.mil 


COSMOS  Orientation 

Viewing  war  as  art  rather  than  science 

•  Problem  of  complexity 

•  Role  of  chance 

•  Prompting  of  intuition 

•  Question  of  form 


Slide  2 

Today  I’ll  be  talking  about  Art  and  its  value  as  an  approach  to  addressing  large  complex 
problems.  The  COSMOS  ACTD  proposes  to  address  a  large  and  complex  problem,  the 
challenge  of  integrating  coalition  C3  networks,  and  of  sharing  information  across  boundaries. 

I  will  be  talking  about  these  themes  in  the  context  of  network  design  and  efficient  sharing  of 
information.  They  are  the  reason  that  war  is  an  art  form  and  not  a  science.  They  apply  to  all 
aspects  of  war  and  not  just  the  business  of  C3,  but  I  suggest  that  they  have  a  particular  relevance 
to  Net-Centric  warfare.  And  although  we  often  speak  of  the  art  of  war,  we  do  little  to  prepare 
ourselves  to  operate  in  the  realm  of  war,  which  is  the  realm  of  art  rather  than  science. 
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The  COSMOS  ACTD  will  introduce  us  to  Net-Centric  operations  squarely  situated  in  the  realm 
of  art.  And  I  believe  it  will  offer  us  valuable  insight,  not  only  into  how  to  better  share 
information  with  our  allies,  but  more  importantly,  on  how  best  to  design,  manage,  and  fight  the 
GIG. 


Ideas  on  the  Nature  of  Art 

Aristotle;. 

“All  art  is  concerned  with  coming  into  being,  with  considering 
and  contriving  how  something  may  come  into  being." 

“Art  loves  chance,  and  chance  loves  art." 

Dante: 

No  artistic  expression  is  possible  without  constraint,  “the 
Curb  of  Art." 

Hegel. 

u  Architecture  levels  a  space  for  the  concentration  of  spirit  and  for 
its  direction  to  the  mind’s  absolute  objects.” 


Slide  3 

Here  are  some  ideas  on  the  nature  of  art  that  I  ask  you  to  keep  in  mind  as  we  go  through  this 
briefing.  Art  has  always  been  man’s  way  of  reconciling  reality  with  the  ideal.  Our  rational 
capacity  permits  us  to  glimpse  perfection,  and  yet  our  capacity  for  reason  tells  us  that  it  will 
always  remain  beyond  our  grasp.  It  is  in  reconciling  the  dynamic  tension  between  what  is  and 
what  might  be  that  man’s  creative  powers  are  summoned. 

According  to  Aristotle,  art  is  all  about  this  reconciliation  between  the  cognitive  process  of 
considering  on  the  one  hand,  and  the  physical  process  of  contriving  with  or  manipulating  the 
materials  on  the  other.  Chance  is  the  leaven  that  somehow  causes  the  imagination  to  rise  to  new 
insights,  which  in  turn  affect  both  the  considering  and  contriving. 

Dante’s  idea  is  of  particular  interest;  that  no  art  is  possible  unless  this  struggle,  this  “coming  into 
being”  takes  place  under  the  pressure  of  some  severe  constraint.  The  “Curb”  or  constraint  that 
Dante  labored  under  was  the  dual  yoke  of  rhyme  and  meter.  By  subjecting  himself  to  the 
discipline  of  writing  in  rhymed  couplets,  he  imbued  his  “Divine  Comedy”  with  a  gripping 
forward  momentum  that  propels  the  reader  onward  in  anticipation  of  the  resolution  of  the  next 
metered  set.  The  rhyme  and  meter  set  the  “context  for  understanding.” 
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Hegel’s  view  of  architecture  (which  he  considered  a  fine  art)  has  relevance  for  our  concept  of  the 
GIG.  Just  insert  the  word  “Network”  in  front  of  this  paraphrased  quote  from  his  Lectures  on  The 
Aesthetic  and  I  think  you  will  see  what  I’m  getting  at.  Concentration  of  spirit  has  to  do  with 
supporting  the  capacity  for  intuitive  reasoning  and  judgment,  while  giving  “direction  to  the 
mind’s  absolute  objects”  has  to  do  with  implementation  of  vision.  This  process  of  “considering 
and  contriving”  within  the  “leveled  space”  of  a  global  information  grid  is  the  essence  of  Net- 
Centric  warfare.  The  COSMOS  ACTD  is  about  preparing  us  to  be  both  architect  and  artist. 

But  before  we  jump  into  the  realm  of  war,  I  think  a  few  words  about  training  are  in  order.  Our 
concept  of  training,  and  by  extension  our  understanding  of  the  wartime  demands  on  our 
networked  communications  architecture,  falls  short  of  the  demands  of  art. 


Training  Environment 

(Realm  of  Science) 


Physical 


Contriving 


Cognitive 

Considering 


Complexity  effectively  but 
artificially  constrained 


•  Comptroller  rules 

•  Chance  plays  marginal  role 

•  Variables  controlled,  duration 
limited 

•  Outcomes  predetermined  or 
predictable 


Slide  4 

Here’s  how  I  see  the  Training  Environment.  With  Chance  effectively  marginalized  it  falls  short 
of  the  realm  of  Art.  Due  to  real  limitations  on  time,  money,  men,  and  equipment,  we  have 
effectively  removed  chance  as  a  leavening  factor. 

In  one  sense  this  is  a  good  thing,  because  it  allows  us  to  focus  our  concentration  in  a  few  areas  or 
even  upon  a  single  variable  with  a  view  toward  achieving  predictable  results.  Isolating  variables 
and  the  disruptive  intrusions  of  chance  is  exactly  what  we  do  when  we  apply  the  Scientific 
Method  (another  contribution  of  Aristotle’s)  to  learn  something  about  the  nature  of  things.  It  is  a 
powerful  human  tool  that  relies  on  the  interplay  between  the  “Considering”  and  the 
“Contriving,”  to  enable  us  to  walk  the  cause  and  effect  chain  backwards  and  thereby  dissect  in  a 
limited  way  the  empirical  world  we  inhabit.  It  works  best  in  the  laboratory. 
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The  problem  with  training  that  takes  place  within  the  Realm  of  Science  is  that  we  learn  nothing 
of  Complexity,  a  potentially  lethal  vulnerability  in  war. 

Although  heavily  influenced  by  the  contributions  of  science,  War  lives  within  the  realm  of  Art, 
and  so  must  the  networks  we  rely  on  to  maintain  our  vaunted  information  advantage.  They  must 
be  tuned  to  deal  with  the  lethal  threat  of  complexity,  that  is  to  say,  they  must  be  designed  with  a 
specific  purpose  in  mind,  and  they  must  be  efficient.  Nature  abhors  inefficiency,  and  war  is 
Natural  Selection  on  Steroids!  Only  an  efficient  network  can  assure  the  timely  delivery  of  the 
right  information  to  the  decision  maker  that  needs  it. 


Combat  Environment 

(Realm  of  Art) 


Physical 


Cognitive 


Considering 

k-  ==5$f— 

^  Chance  ^ 

*  Chance  rules 


Complexity  tends  toward  the 
hyperbolic  ....  Unless 
constrained  by  form 


*  Variables  unlimited,  duration 
open  ended 

*  Enemy  has  a  vote 

*  Outcomes  less  predictable  or 
perhaps  undeterminable 
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Clausewitz  described  war  as  the  “Realm  of  Chance”!  Its  influence  and  direct  relationship  to  the 
challenge  of  Complexity  were  apparent  well  before  the  first  computer  network  both  enriched  and 
complicated  our  lives. 

Where  Chance  Rules,  variables  become  unlimited,  outcomes  less  predictable,  and  as  Clausewitz 
noted,  “even  the  simple  things  are  difficult.” 

When  simple  things  become  difficult  you  can  be  assured  that  it  is  not  just  the  enemy  registering 
his  vote  that  is  the  cause. 

Complexity  if  unconstrained  moves  toward  the  hyperbolic.  I  believe  that  this  is  a  potentially 
lethal  vulnerability  in  the  Net-Centric  environment  where  computer  networks  are  supersensitive 
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to  feedback  loops  that  can  turn  our  information  systems  into  purveyors  of  ever  increasing 
volumes  of  irrelevant  data. 

Commander’s  drowning  in  torrents  of  useless  information  is  symptomatic  of  a  communications 
architecture  that  is  ill  conceived,  unbalanced,  inefficient,  and  succumbing  to  spiraling 
complexity. 

Our  only  hope  of  constraining  complexity  in  our  C3  architecture  is  by  imposing  form  suited  to  its 
purpose,  the  way  of  art.  It  begins  as  Hegel  observed  by  “leveling  the  space,”  by  approaching 
network  design  as  an  art  form. 

In  Operation  Iraqi  Freedom  concerns  with  releasibility  of  information  among  allies  forced  us  to 
segregate  coalition  partners  in  separate  CENTRIXS  domains.  It  seems  that  the  purpose  of  the 
CENTRIXS  architecture  was  to  frustrate  rather  than  promote  integration.  The  need  for 
information  protection  rather  than  information  sharing  drove  design  considerations. 


COSMOS 

Operational  Problem 


CONFUSION 


■  CENTRIX  is  segregated  into 
separate  domains 

■  Separate  domains  and 
incompatible  data  models 
force  all  coalition 
communications  into  the  text 
realm 

■  Text  communications  are  too 
slow,  inefficient,  and  inherently 
inaccurate 
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Despite  the  difficulties  encountered  in  OIF  we  have  made  no  changes  in  the  CENTRIXS 
architecture  and  in  fact  continue  to  add  separate  “stove  piped”  domains,  one  for  each  new 
coalition  partner.  Separate  CENTRIXS  domains  are  crushingly  inefficient  on  the  battlefield.  It 
forces  us  to  field  additional  equipment  and  restricts  coalition  communications  to  the  text  realm, 
where  translation  burdens  add  further  delay  and  inaccuracy. 
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Confusion,  Delay  and  Uncertainty,  all  manifestations  of  the  phenomenon  of  complexity,  are  facts 
of  life  on  the  battlefield.  To  be  rid  of  them  would  be  ideal.  We  know  from  Art  that  while  the 
Ideal  is  unachievable,  it  is  not  unapproachable.  We  need  a  CENTRIXS  network  architecture  that 
shrinks  the  Psychological  space  defined  by  these  three  battlefield  facts  of  life.  That  is  to  say,  we 
need  a  network  design  that  constrains  complexity,  promotes  integration  over  segregation,  and  a 
data  scheme  that  permits  the  direct  exchange  of  information  machine -to-machine. 

We  need  a  new  architectural  vision  for  CENTRIXS,  in  which  the  purpose  of  the  network  is 
viewed  as  the  integration  of  coalition  efforts  as  opposed  to  the  restriction  of  access  to 
information. 


COSMOS  Requires 
A  Transformational  Solution 

•  Because  the  problem  of  complexity  is  growing 
exponentially  leaving  our  inefficient  networks  prone  to 
catastrophic  failure 

•  Because  our  potential  adversaries  are  becoming 
more  sophisticated  in  their  abilities  to  exploit  the 
inefficiencies  of  our  networks. 

•  Because  Net-Centric  warfare  will  demand  agility  and 
flexibility  that  our  current  network  architecture  cannot 
provide 
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We  need  to  move  the  Coalition  C3  effort  from  the  disconnected  “stove  piped”  reality  we 
experience  today  to  the  realm  of  Art  where  form  supported  by  the  concepts  of  balance  and 
proportion  offer  the  only  hope  of  constraining  complexity. 

I  believe  that  a  transformational  solution  to  the  problem  of  coalition  integration  is  advisable  for 
what  it  can  tell  us  about  the  much  larger  challenge  of  designing  and  managing  the  GIG.  The 
tools  of  art  applied  to  the  challenge  of  managing  complexity  in  the  coalition  arena,  are  also 
applicable  to  the  much  greater  challenge  of  designing  the  GIG  to  function  in  the  realm  of  war. 
The  concept  of  Dante’s  Curb  of  Art  is  really  the  key  to  understanding  how  an  artistic  solution 
applied  to  the  more  manageable  problem  of  coalition  integration  on  the  battlefield  can  be 
expanded  to  address  the  challenge  of  integrating  COI  across  a  global  grid. 
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COSMOS 

Conceptual  Solution 

*  Use  a  common  data  model  to  enable  the  automatic  sharing 
of  information  (data  in  context)  at  the  machine  level  and 
unleash  the  potential  of  smart  agent  technology 

*  Collapse  the  multiple  coalition  domains  down  to  a  single 
integrated  network  while  maintaining  cryptographic 
segregation  of  allied  access  to  a  “Shared  Space”  where 
coalition  data  is  accessible 

*  Tag  information  for  automatic  release  to  selected  coalition 
members  based  on  role 

*  Demonstrate,  through  Exemplar  applications,  the  exchange 
of  “data  in  context”  across  service  and  national  boundaries 
independent  of  application 
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“Leveling  a  space  for  the  concentration  of  spirit  and  for  its  direction  to  the  mind’s  absolute 
objects”  was  Hegel’s  challenge  to  architects.  Our  task  is  to  define  a  virtual  space  that  promotes 
the  integration  of  coalition  efforts  in  the  combat  theater. 

Collapsing  the  CENTRIXS’  domains  down  to  a  single  integrated  network  does  not  require  that 
we  abandon  access  controls  over  classified  data.  It  does  require  that  we  establish  a  purpose  for 
the  network,  and  then  let  that  purpose  define  the  form  or  architecture.  The  objective  of  COSMOS 
is  to  integrate  coalition  communications  in  such  a  way  as  to  enable  the  full  potential  for  data 
exchange  in  the  Net-Centric  environment.  This  purpose  then  drives  the  form,  the  collapsed 
network  with  access  to  a  shared  space  where  coalition  data  is  accessible.  The  form  enables  or,  to 
paraphrase  Frank  Lloyd  Wright,  “follows  function.”  The  form,  if  balanced  and  suited  to  its 
purpose,  also  gives  us  an  approach  to  constraining  complexity. 

The  greater  challenge  in  applying  the  principles  of  art  to  coalition  integration  is  to  select  Dante’s 
Curb!  What  yoke  or  constraint  can  we  shoulder  in  order  to  release  the  creative  advantage  of 
intuitive  thinking,  and  bend  our  collective  wills  relentlessly  toward  the  dictates  of  efficiency? 

My  answer  is  that  the  data  model  can  serve  the  same  purpose  of  rhyme  and  meter  in  poetry  and 
provide  the  “context  for  understanding,”  the  essential  precondition  for  all  efficient 
communications.  The  data  model  can  provide  the  “context  for  understanding”  that  enables  the 
sharing  of  information  across  boundaries,  independent  of  application.  The  data  model  can  help 
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generate  a  forward  momentum  in  our  communications  that  anticipates  need  and  pushes  critical 
information  to  the  individual  that  needs  it. 

The  COSMOS  ACTD  will  demonstrate  the  potential  of  purposeful  form  in  network  design,  and  a 
common  data  model  to  effectively  integrate  coalition  communications. 


COSMOS 

Technical  Approach 

•  Employ  VPN  technology  and  if  available  CBIS  encryption  to  maintain 
cryptographic  separation  among  allies  accessing  the  shared  space 

*  Demonstrate  the  usefulness  of  a  common  data  model(s)  for  exchange 
of  "data  in  context"  across  boundaries.  Since  Command  and  Control 
cuts  across  all  COI(s),  begin  with  the  C2  data  model  adopted  by  NATO 
and  endorsed  by  DISA  for  NCES  interaction,  C2IEDM 

•  Bridge  Exemplar  Applications  to  the  common  data  model  using  Open 
Standard  Software  Development  methodologies 

*  Leverage  Smart  Agent  and  Portal  technology  to  meet  user  defined  info 
requirements 
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The  technology  is  not  the  biggest  challenge  in  implementing  the  COSMOS  vision.  There  are 
several  encryption  technologies  we  can  explore,  either  separately  or  in  combination,  to  safeguard 
information  in  the  shared  space.  The  challenge  of  bridging  legacy  applications  to  the  C2IEDM 
model  is  also  manageable.  And  the  use  of  intelligent  agent  and  portal  technology  to  find  and 
display  vital  information  on  the  screens  of  key  decision  makers  is  practical  once  the  “leveled 
space”  has  been  established. 

The  greater  challenges  to  realizing  the  potential  of  Net-Centric  operations  are  not  technical  but 
cultural.  We  must  overcome  our  tendency  to  approach  new  network  design  from  the  perspective 
of  the  perceived  shortcomings  of  our  current  systems.  For  example:  more  bandwidth  is  not  the 
essential  challenge  in  designing  the  GIG,  but  certainly  its  inefficient  use  is  a  problem  we  want  to 
avoid.  The  challenge  in  designing  the  GIG  is  defining  its  purpose,  and  aligning  the  Communities 
of  Interest  (COI)  whose  participation  is  essential  to  its  successful  implementation. 

I  believe  that  the  greatest  risk  in  undertaking  a  project  of  the  size  and  scope  of  the  GIG  is  our  old 
adversary  “Complexity.”  The  larger  the  networked  architecture,  the  more  opportunity  for 
inefficiency  to  gain  an  upper  hand  and  drive  complexity  to  destructive  levels,  especially  in  time 
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of  war.  Our  only  chance  of  managing  the  threat  of  complexity  is  through  “form  imbued  with 
purpose,”  which  by  the  way  is  Immanuel  Kant’s  definition  of  Art. 

I  will  not  presume  to  propose  a  form  for  the  GIG.  On  the  one  hand,  I’m  not  smart  enough,  and  I 
don’t  have  a  clear  enough  understanding  of  its  intended  purpose  on  the  other.  But  I  know  that  I 
am  on  safe  ground  when  I  say  that  the  COSMOS  ACTD  will  generate  insights  into  Net-Centric 
reality  on  a  small  scale.  And  that  some  of  these  insights  will  be  of  great  value  in  the  overall 
design  and  implementation  of  the  GIG.  And  I  suspect  that  the  “Curb  of  Art”  that  we  propose  for 
the  COSMOS  ACTD  to  provide  the  “context  for  understanding”  that  enables  the  exchange  of 
data  across  boundaries,  will  serve  the  same  purpose  equally  well  for  the  GIG. 


Here’s  a  conceptual  view  of  the  collapsed  CENTRIXS  network  that  will  provide  the  “leveled 
space”  for  the  exchange  of  information  or  “data  in  context”  across  boundaries  and  independent 
of  application. 

The  applications  depicted  are  COSMOS  exemplars  bridged  to  the  C2IEDM  model.  We  have 
borrowed  the  term  exemplar  directly  from  philosophy  where  it  refers  to  individuals  or  systems 
that  embody  those  traits  or  virtues  one  hopes  to  spread  throughout  the  larger  society.  We  want  to 
demo  exchange  of  “data  in  context”  or  information  machine -to-machine  among  different  service 
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and  national  applications.  And  we  expect  to  gain  important  insight  into  Net-Centric  reality  in  the 
process 

The  FORM  of  the  collapsed  network,  and  the  advantages  in  efficiencies  it  offers  over  the  current 
stove-piped  arrangement  of  CENTRIXS  domains,  is  obvious.  What  is  not  so  obvious,  but  is 
perhaps  of  greater  importance,  is  the  empowerment  that  compliance  with  Dante’s  Curb  of  Art 
offers.  It  is  of  course  the  shouldering  of  the  Curb  or  constraint  of  the  data  model  that  enables  the 
exchange  of  “data  in  context”  and  it  is  the  virtues  associated  with  the  efficient  exchange  of  this 
information  that  we  want  to  inculcate  in  the  larger  society  of  the  GIG.  These  virtues  include: 

*  The  ability  to  discretely  tag  data  as  releasable  to  different  members  of  a  coalition  based 
on  role  or  some  other  criteria. 

*  The  ability  of  intelligent  agents  to  glean  critical  data  elements  from  diverse  sources  and 
display  them  in  the  manner  most  useful  to  decision  makers. 

*  The  ability  to  shift  much  of  our  communication  from  the  text  realm  to  machine-to- 
machine,  thus  eliminating  much  of  the  human  handling  and  translation  requirements. 

*  The  ability  to  support  intuitive  reasoning  by  enabling  commander’s  to  adjust  the 
quantity,  variety,  and  content  of  information  that  competes  for  their  attention. 


The  NATO  C3  Agency  employs  the  C2IEDM  as  the  data  model  for  exchanging  C2  data  among 
the  20  allied  nations  of  the  alliance. 
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Partnering 

Agencies  and  Allies 

•  OSD  Nil 

•  Australia 

•  DISA  NCES  &GE2 

•  Canada 

•  DUSD  AS&C 

•  UK  (tentative) 

•  USMC 

•  NATO  C3  agency 

•  USA 
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These  are  the  nations,  services,  and  agencies  that  have  signed  up  to  support  COSMOS.  We  are 
recruiting  COI  that  have  a  crucial  interest  in  exchanging  data  across  boundaries.  We  think  that 
the  COSMOS  experience  will  help  them  get  organized  and  give  them  a  head  start  in  determining 
what  data  under  their  control  should  be  shared  across  the  network. 

The  process  of  identifying  COI  and  encouraging  these  self-  organizing  entities  to  commit  their 
data  to  be  shared  across  the  GIG  has  been  identified  by  the  GAO  as  one  of  the  fundamental 
challenges  to  implementation  of  the  DOD’s  GIG  vision.  The  sharing  of  data  by  COI  does  not 
mean  the  adoption  of  a  common  data  standard,  but  rather  the  mapping  of  data  elements  to  be 
shared  to  the  common  data  model. 

I  believe  that  the  COSMOS  ACTD  can  play  an  important  role  in  providing  COI  with  a  glimpse 
into  the  Net-Centric  future  and  thereby  assist  them  in  preparing  for  it. 
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Expected  Benefits 


Resolves  operational  problems 

First 

Order 

J Reduction  of  complexity  and  equipment  duplication 
^Support  machine-to-machine  exchange  of  vital  info 
^  Redu  cti  on  o  f  t  ext  tra  fft  c  an  d  tra  ns  lati  on  burd  en 

Doctrinal  Solution  for  implementing 

DoD's  Net  Centric  Data  Strategy 

OUirUI  VkJ 

Order 

/  Pathfinder  for  the  DOD  Net  Centric  Data  Strategy 
^  Extensions  to  the  data  model  in  support  of  COfs 
v"  Assessment  of  CDR  s  Info  needs  as  a  GIG  design  criterion 

Transformation 

Third  Order 

^Insight  into  NetCentric  information  flow 
^Insight  into  the  optimal  form  of  the  GIG 
^Insight  into  how  to  Tight  the  GIG" 
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The  expected  benefits  of  COSMOS  are  intellectual  products  rather  than  hardware  or  software 
products.  The  first  order  of  magnitude  benefits  address  the  operational  problems  with  coalition 
communications  experienced  in  OIF.  But  the  “form  imbued  with  purpose,”  and  the  “Curb  of 
Art”  used  to  realize  these  first  order  benefits  have  implications  that  extend  well  beyond  the 
combat  theater.  Addressing  the  challenges  of  coalition  integration  at  the  operational  level  of  war 
with  the  tools  of  art  offers  insights  and  possible  solutions  to  the  much  larger  and  more  complex 
strategic  challenges  we  face  in  implementing  the  DOD  vision  for  the  GIG.  The  second  and  third 
order  benefits  of  COSMOS  will  provide  valuable  insights  that  might  save  time  and  money  in  this 
$2 IB  effort. 

The  July  2004  GAO  report  entitled  “The  Global  Information  Grid  and  Challenges  Facing  its 
Implementation”  lists  several  concerns  to  include: 

*  The  challenge  of  implementing  a  project  of  this  magnitude. 

*  The  inherent  risks  of  protecting  data  within  the  thousands  of  systems  to  be  integrated 
into  the  network. 

*  The  challenges  of  sharing  information  across  business  and  war-fighting  operations. 

*  The  implications  of  sharing  time  sensitive  data  in  NetCentric  operations. 

*  The  identification  of  COI  and  the  processes  for  their  collaboration  in  the  sharing  of 
data. 

*  The  implementation  of  a  DOD  Net-Centric  data  strategy. 
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*  The  requirement  for  a  roadmap  for  DOD  components  to  follow  in  migrating  their 
systems  to  the  GIG. 

In  conclusion  the  GAO  noted,  “  While  DOD’s  vision  of  the  GIG  is  compelling,  the  breadth  and 
depth  of  the  GIG  and  DOD’s  objectives  for  net-centric  warfare,  present  enormous  challenges  and 
risks  -  many  of  which  have  not  been  overcome  in  smaller  scale  efforts,  and  many  of  which 
require  significant  changes  in  DOD  culture.” 

The  COSMOS  ACTD  is  a  small-scale  effort  that  proposes  to  employ  the  most  powerful  tools  the 
rational  mind  has  yet  to  devise  for  tackling  complex  problems,  the  tools  of  art.  I  think  its  an 
investment  worth  making. 
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Delivering  Joint  and  Coalition 
Interoperability  at  the  Information 

Level 

ONR  Symposium  Quantico 

8  September  2004 

Project  Manager 
Intelligence,  Surveillance,  Target 
Acquisition  and  Reconnaissance  -  Omnibus  (PM  ISTAR) 


LCol.  Jacques  Hamel 

The  Canadian  Forces 
Project  Manager,  ISTAR 

Good  morning  ladies  and  gentlemen.  Twenty-one  years  ago,  I  was  walking  into  Courthouse  Bay 
in  Camp  Le  Jeune  to  learn  about  some  of  my  trade  as  an  engineer  officer.  Today,  I’m  visiting 
the  Marine  Corps  Base  at  Quantico  to  talk  about  what  we’re  doing  in  Canada  as  a  partner  in  this 
interoperability  issue  with  the  U.S.  Many  of  our  lessons  are  the  same  as  yours  we’re  moving 
down  the  same  road  with  the  same  pain. 
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My  Community  of  Interest  as  Project  Manager  of  ISTAR  are  the  warfighters,  from  the  soldiers  to 
the  naval  task  groups.  I  started  as  an  integrator  for  the  land  warfighter  that  brings  in  the  joint  and 
multinational  picture.  This  is  not  a  simple  problem,  because  all  of  those  communities  out  there, 
the  legacy  that  they're  pulling  behind  them,  makes  your  cost  go  up  and  makes  your  complexity 
go  up.  We  have  to  find  a  way  to  bring  that  down  and  one  of  those  elements  was  discussed  earlier 
by  Dr.  Pohl. 

We  all  have  the  same  information  needs  on  the  battlefield,  be  you  Army,  Marines,  Navy,  or  Air 
Force.  You  all  have  the  requirements  to  know  where  we  are,  know  what  the  force  is  of  our 
enemies  or  belligerence.  We  need  to  understand  the  environment  and  the  conditions  of  the 
environment.  We  need  to  understand  the  situation.  But,  most  importantly  we  need  to  understand 
the  context  in  which  it’s  presented,  be  it  overlays,  fusion,  or  another  element,  you  need  to 
understand  this  context.  Without  the  context,  the  linkages  are  missing. 


Battlefield  Information  Needs 


* 


* 
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Friendly  or  Enemy  Forces 


-  Force  Composition,  Disposition, 
Sustainment 

-  Mobility  and  Transportation 

-  Weapon  Systems  and  C4I 

Environmental  Conditions 

-  Physical  (Land,  Sea,  Air,  Space) 

-  Civil  (Political,  Cultural,  Economic) 

Situation  Awareness 


-  Mission,  Intelligence,  Targeting 

•  Operational  Context 


Currently,  when  you’re  driving  up  the  information  chain,  most  of  what  we’ve  been  able  to  do, 
dealing  with  automation,  maintaining  the  information  layer,  dealing  with  knowledge, 
understanding  and  the  ability  to  predict,  is  still  in  the  realm  of  the  human  today,  because  we 
haven’t  been  very  good  at  quantifying  where  we’re  going  and  the  people  we  are  fighting  don’t 
seem  to  want  to  be  predictable  anymore. 
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Our  area  of  operations  has  also  changed  dramatically.  What  used  to  be  core  area  of  operations 
now  can  be  the  responsibility  of  a  brigade,  or  in  some  case  in  lower  level  operations  of  a  battle 
group.  So,  there  is  the  need  for  surveillance  in  the  areas  of  200  kilometers  or  more,  with  the 
ability  to  target  within  areas,  specific  areas  or  managed  routes,  and  be  able  to  track  those  target’s, 
to  be  able  to  either  maintain  that  knowledge  about  them,  or  to  be  able  to  prosecute  them.  This  is 
a  tall  order  if  you  were  to  do  it  the  old  way. 


In  order  to  get  there  we  have  to  adopt  a  service  model.  The  simplification  of  it,  our  backbone  is 
our  network.  No  different  than  your  GIG  architecture,  but  what’s  important  in  there  is  there  are 
three  services  within  that  model  that  will  repeat  themselves  throughout.  The  information  that 
we’re  sharing,  the  management  and  support  of  the  environment,  and  the  security.  We  didn't  talk 
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about  security  earlier  today,  but  this  is  the  toughest  problem  to  crack  in  order  to  maintain  joint 
multi-national  and  interagency  capabilities,  especially  when  you’re  dealing  with  different 
security  levels. 
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You  have  to  have  sensors  coming  into  your  service  architecture  and  finally,  we  need  to  put  the 
brain  bucket  in  there.  Again,  there’s  one  thing  that  transcends  everything  and  this  is  where  the 
human  comes  in.  All  of  this  automation  is  only  possible  if  we  have  common  procedures  or 
repeatable  procedures  of  some  sort.  So,  we  can  either  impart  them  to  the  machine  or  we  can  get 
people  to  understand  what  they’re  using.  To  drive  it  from  the  network  up.  You’re  going  to  end 
up  with  this  joint  procedure  at  the  top.  You  have  to  get  it  down  the  other  way  around,  which  is 
from  the  procedures  down,  meaning  the  warfighter  is  involved  from  the  beginning.  This  is  not  a 
simple  process,  because  we  tend  to  get  nervous  when  we  hear  the  word  “network”. 
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Today  in  Canada,  like  in  the  U.S.,  we  seem  to  have  cracked  the  technology  side.  Technology  is 
now  something  we  can  manage.  We  can  move  forward  on  it.  We’re  slowly  integrating  at  the 
information  level.  It’s  going  to  take  a  while  longer,  but  our  procedures  and  organizations  that  are 
supporting  the  warfighters  aren't  what’s  dragging  us  back.  It’s  going  to  be  a  couple  more  years. 
We  need  to  work  with  it  to  get  forward  and  to  actually  get  the  advantage  that  we’re  looking  for. 


Classically,  when  we  look  at  interoperability,  we’ve  been  looking  at  the  network  interoperability 
as  driving  the  command  and  control  of  the  information  probability.  And,  classically,  it’s  easier  if 
you’re  doing  it  from  yourself,  be  it  the  Army  or  Marine  Corps  or  the  Navy  than  looking  at  your 
national  joint  level,  and  then  looking  at  your  allies,  because  the  complexity  grows  as  you  go  out. 
Both  from  the  networking  and  a  security  perspective.  What  we  found  in  our  own  work 
nationally,  it’s  not  true  when  you’re  dealing  with  the  information  itself  or  the  applications. 
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We  found  through  our  work  that  started  by  looking  at  papers  written  in  this  country  in  the  mid 
90s  that  was  easier  if  you  start  with  your  allies,  because  at  the  information  and  functional  level  is 
what  we  have  the  least  in  common.  We  have  a  small  amount  in  common.  The  processes  are 
fairly  simple  because  our  doctrine  are  all  a  little  bit  different,  and  therefore  if  you  start  with  your 
allies  and  you  grow  to  deal  with  your  joint  problem  and  then  your  single  service  problem  at  the 
end,  life  is  easier.  So  starting  in  the  mid  90s,  Canada  put  in  an  investment  into  looking  at  the 
future  from  an  interoperability  perspective.  This  became  the  primary  interface  point  that  we  did 
from  a  command  and  control  information  perspective,  at  the  same  time  as  we  were  looking  at 
other  interface  points  I’ll  discuss  later. 


One  of  the  changes  that  we’re  looking  at  right  now,  that’s  coming  from  here  conceptually,  is  the 
change  in  how  the  intelligence  process  is  working.  As  the  PEO  responsible  for  all  ISTAR 
Projects  within  the  Canadian  Army,  I  need  to  be  able  to  go  from  the  old  process  to  the  new 
process;  the  concept  is  there,  but  I  can  tell  you  that  people  may  not  understand  the  process  yet, 
and  it’s  slowly  changing,  but  as  we  get  forward  this  will  fundamentally  change  how  we  work 
below  the  surface.  By  going  there  multinationally,  understanding  the  TPPU  process 
multinationally  first  before  we  try  to  derive  our  own  tactical  sensors  into  it,  life  becomes  easier, 
and  we  demonstrated  that  a  couple  weeks  ago  when  we  engaged  in  a  Canadian  exercise  that  had 
multinational  components. 

In  our  problem  area,  we  have  to  deal  with  most  of  the  information  coming  from  an  unstructured 
be  it  free  text,  imagery,  video,  voice  to  very  structured  information.  We  made  a  conscious 
decision  to  concentrate  on  structured  information,  however,  in  order  to  prevent  significant  data 
incest.  The  main  thing  is  contacts  and  linkage  back  into  your  unstructured  information,  so 
you’re  able  to,  once  you’ve  done  the  analysis  image,  or  you’ve  extracted  the  concept  from  the 
text,  know  that  what  you’ve  created  as  information  for  the  warfighter  came  from  that  source.  So 
you  don’t  lose  the  context.  Otherwise  you  may  be  at  risk  of  reprocessing  the  same  image  twice, 
or  reprocessing  the  same  information  twice.  So,  from  our  perspective,  we’re  looking  at  four 
large  databases  or  data  sources.  They’re  not  specifically  RDBMS  or  otherwise,  but  we’re 
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dealing  with  operational  data  as  one  Community  of  Interest  from  a  C2  domain.  We’re  dealing 
with  Geomatic  data,  they  were  there  before  most  of  us;  the  NEMA  community  started  very,  very 
early  at  structuring  the  information.  We’re  dealing  with  multimedia  information,  be  it  imagery, 
GMTI  or  voice,  and  we  have  the  quintessential  problem  of  documents.  None  of  us  have  high 
standards  and  right  now  this  is  one  of  the  areas  where  we  need  to  get  better  at.  Otherwise,  they 
become  the  boat  anchor.  So  those  are  the  four  forms  of  information  we’re  dealing  with,  and 
trying  to  assemble  the  ISR  architecture  in  Canada. 


The  Problem  Area 
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So,  what’s  the  data  model?  My  simple  way  of  the  world,  there’s  an  academic  way  of  looking  at 
it,  but  as  a  warfighter  I  have  to  look  at  it  in  terms  that  are  easily  explained  to  the  people  using  it. 
It’s  their  dictionary  and  their  grammar.  In  this  case,  what  we  have  to  look  at  is  find  the  form  of 
Esperanto  where  the  human  can  talk  to  the  machine,  and  the  machine  would  understand  it. 
When  two  machines  would  talk  to  one  another  and  they  would  understand  one  another.  If  you 
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talk  to  the  next  human  in  its  own  language  they  will  still  understand  the  intent  and  the  context. 
This  is  critical.  We  can  do  that  today  with  Geomatic  information  and  command  control 
information  based  on  the  C2IEDM.  We’re  slowly  getting  there,  to  do  the  same  thing  on 
multimedia  information.  It's  very  hard  with  documents. 


Why  a  Data  Model? 


•A  specification  of  the  data 
structures  and  business  rules 
needed  to  represent  and 
support  a  business  area. 

•It  is  the  dictionary  and 
grammar  used  by  humans 
and  systems  to  communicate. 


So  what  we  did  is  we  started  with  the  core,  the  C2IEDM,  and  built  around  it  natural  extensions. 
You  don’t  have  to  be  stuck  to  only  using  the  international  domain.  As  long  as  you  respect  some 
rules  in  building  your  own  model,  you  can  extend  it  to  deal  with  security  issues,  issues  of  purely 
national  means,  and  from  there  build  the  ontology  to  the  point  where  you  can  use  it.  Our  initial 
need,  interestingly,  was  not  warfighting.  It  was  in  the  mid  90s'  fiscal  crisis.  We  had  to  figure  out 
where  we  were  spending  money  on  what,  so  there  was  a  fair  amount  of  extensions  done  to  deal 
with  financial  management,  and  performance  management,  for  the  Army.  So  that  was  where  it 
started,  and  it  also  went  into  the  warfighting  around  where  were  truer  to  the  international  domain 
with  some  extensions. 
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So  what  we  looked  at  for  extensions  for  ORBAT  management  and  how  we  task  organized. 
Intelligence  and  EW,  subjects  that  don’t  get  shared  easily  internationally  or  in  large  international 
communities.  Operational  Planning  because  we  all  do  it  a  little  bit  differently.  Security 
Labeling,  be  able  to  deal  with  guarding  of  information.  Materiel  Management  for  the 
logisticians.  Human  Resource  management,  because  internationally  all  we  care  about  is  the 
number  of  soldiers  you’ve  got;  you  don’t  need  to  know  all  the  details  to  manage  their  health,  or 
the  information  about  them.  In  our  case.  Financial  Management  was  another  extension  we  did. 


National  Extensions 

•  ORBAT  Management. 

*  Intelligence  and  EW. 

•  Operation  Planning. 

•  Security  Labeling. 

•  Materiel  Management. 

•  Human  Resources. 

•  Financial  Management. 

Building  a  data  model  alone  is  not  enough.  This  only  walks  you  through  a  small  amount  of  the 
capability.  The  next  element  you  have  to  look  at  is  the  dynamic  nature  of  the  warfare,  and  look 
at  how  you  will  partially  replicate  the  data  around  the  battlefield  in  order  to  serve  each 
commander.  If  you  replicate  everything  everywhere,  you’ll  never  have  enough  bandwidth.  If 
you  don’t  replicate  enough,  they  won’t  have  the  common  relevant  picture  of  their  level.  So  it’s 
important  to  understand  the  dynamic  and  have  this  process  that’s  managed  based  on  the 
commander’s  CCIR  and  therefore  it's  based  on  ownership  management,  rules  and  filters 

If  you  have  a  data  model  and  you  have  no  means  of  having  a  unique  addressing  scheme  the 
same  as  the  internet  using  IPV4  address  to  make  sure  we  all  have  a  different  address  on  the 
network,  and  we’re  running  out  of  addresses,  you  have  to  do  the  same  thing  with  your  data 
element.  A  data  element,  information  element,  has  to  be  uniquely  identified  worldwide  and 
inside  your  Community  of  Interest,  otherwise  two  of  you  will  use  the  same  postal  address  or  the 
equivalent,  and  you’ll  end  up  with  significant  system  crash.  This  is  the  legacy  of  the  messaging 
environment  where  you  could  reprocess  the  same  message  and  get  information  twice.  This  is 
something  that  must  be  managed  in  the  environment 

Next  is  data  ownership  rules  and  respecting  it,  and  the  implications  for  both  security  and 
operational  use  of  that  data.  To  create  data  on  a  data  element  that  belongs  to  one  of  your  allies 
or  belongs  to  somebody  else  inside  your  organization.  You’re  not  overwriting  what  they  have 
you  are  amplifying  because  if  you  overwrite  you’re  erasing  the  past  and  erasing  the  past  is  not  a 
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good  thing,  especially  when  you’re  trying  to  deal  with  your  warfighting  systems  where  lives  of 
people  are  at  stake. 


* 


Data  Management  Considerations 


ISUk 


•  Distributed  and  partially  replicated  Data  in  a 
dynamic  system  of  systems. 

•  Meaningless  and  universally  unique 
database  keys. 

•  Data  Ownership  rules. 

•  Data  correlation  and  aggregation  rules. 

•  Data  aging. 


The  next  one  is  not  trivial.  How  do  you  aggregate  and  how  do  you  correlate  data  elements? 
Two  of  us  sent  a  spot  report  on  the  same  tank  on  the  hill  at  two  different  times.  How  do  you  get 
that  correlation  done?  What  are  the  rules  you  want  to  use  there,  and  how  to  you  present 
aggregated  positions,  aggregated  holdings,  aggregated  capabilities?  How  do  you  present  that? 
What  are  the  rules  you  want  to  use  in  this  area?  This  is  the  tougher  part  where  the  warfighters 
have  to  define  how  they  want  to  present  those;  is  it  pure  mathematical  sums  based  on  algorithm 
or  is  it  something  a  little  bit  better  than  that?  Because  right  now  if  you  have  two  companies  on 
one  side  of  the  river,  one  company  on  the  far  side  of  the  river,  you  may  end  up  with  a  battalion 
right  in  the  middle  of  the  river,  which  makes  no  sense. 

The  last  one  but  not  least,  since  the  data  we’re  dealing  with  is  like  for  banking,  the  passage  of 
time  makes  some  of  the  older  data  irrelevant  to  your  current  fight,  you  have  to  deal  with  data 
aging  and  presenting  that  to  the  users,  so  your  user  community  can  represent  what  is  current  data, 
what  is  older  data,  and  what  is  data  that  should  not  be  taken  into  account  anymore.  Data  aging  is 
another  significant  factor  that  must  be  taken  into  account. 

So  earlier  today  we  talked  about  Community  of  Interest.  We  identified  one  of  them.  There’s 
one  out  there  called  the  C2IEDM  community,  MIP  community  where  it  was  a  landcentric 
warfare  community  that  looked  at  command  and  control.  That  Community  of  Interest  was  made 
up  of  a  series  of  smaller  communities  of  interest  that  looked  at  IEW  sustainment,  air  defense 
networks,  fire  support,  personnel.  When  we  all  started  we  thought  we  were  all  very  different. 
I’m  a  combat  engineer  and  I  thought  I  was  very  different  and  my  way  of  command  and  control 
was  very  different  than  the  infantry,  was  very  different  than  the  artillery.  We  got  very  surprised. 
We  have  over  90%  commonality  in  between  the  different  communities  once  you  start  really 
digging  back  down  and  forcing  people  back  to  the  logic  in  what  they’re  saying,  out  of  their 
legacy  into  the  common  logic.  Once  you  find  that  you  have  to  have  90%  commonality,  you  call 
that  common  command  and  control.  You  let  the  special  extensions  to  deal  with  fire  support 
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computation,  air  and  joint  warfare  signals  analysis,  in  that  community.  You  don’t  try  to  impose 
that  on  everybody.  But,  there’s  a  large  amount  of  commonality  that  was  identified  in  doing  the 
work  on  the  C2IEDM.  So  we  went  from  seven  or  eight  BFAs  or  separate  systems  in  Canada. 
We’re  collapsing  to  a  single  one  right  now  for  land  warfare  over  the  next  two  years. 


C2IEDM  Community  of  Interest 


For  me,  under  ISTAR,  which  is  bridging  the  C2  and  ISR  communities,  I  need  to  bridge  other 
communities  of  interest.  I  need  to  be  able  to  bring  in  the  command  and  control  community, 
which  is  one  Community  of  Interest  which  is  important  to  me.  There’s  a  second  Community  of 
Interest  which  is  emerging,  called  CAESAR/MAJIIC,  CAESAR  old  name,  MAJIIC  new  name. 
It’s  sensor  information.  Eleven  nations  in  NATO,  seven  up  to  this  year,  were  dealing  with 
EOIR,  SAR  and  other  sensory  platforms  to  bring  them  together  to  a  common  standard  similar  to 
what  the  MIP  C2IEDM  did,  but  at  the  data  level.  This  is  a  second  Community  of  Interest,  which 
is  critical,  the  naval  and  air  community  have  had  the  Link  Community  of  Interest  for  years,  and  it 
is  a  Community  of  Interest  that  has  to  be  reckoned  with,  because  it  has  specific  characteristics 
tied  to  real-time  operations,  that  must  be  integrated  properly. 

Again,  you  have  the  Community  of  Interest  which  at  its  surface  is  not  information  based,  but  is 
based  on  common  principles,  the  CANUS  or  4EYES  security  or  compartmented  information,  is 
issues  we  have  to  deal  with  if  you  want  to  be  able  to  warfight,  together,  with  your  allies  and  the 
safeguarding  information  of  your  allies.  The  DGIWG  which  is  the  NEMA  based  geographic 
information  community,  is  another  Community  of  Interest.  Those  are  standing  communities  of 
interest  that  do  have  rules  or  data  models  today.  The  data  model  for  DGIWG  is  digest,  the  data 
model  for  the  MIP  is  C2IEDM,  CAESAR/MAJIIC  has  a  series  of  information  models  that  are  at 
the  object  level,  dealing  with  multimedia  capability,  the  Link  Community  of  Interest  has  a  data 
dictionary,  and  the  other  part,  like  I  said  earlier,  is  based  on  rules  at  the  moment.  We  need  to 
expand  that  either  into  the  ability  to  guard  for  reuseability  or  for  the  ability  to  mark  information 
up  with  details  that  are  not  sharable  with  your  other  allies. 
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J&fc  ISTAR  Communities  of  Interest 


•  MIP  (C2IEDM)  -  Command  and  Control 
Information 

•  CAESAR/MAJIIC  -  Sensor  Information 

•  Link  Community  of  Interest  -  Real-time 
Engagement 

•  CAN  US/4  EYES  -  Security  and 
compartmented  Information 

•  DGIWG  -  Geomatic  information 


This  is  all  well  and  good.  As  a  project  manager,  I  can’t  go  anywhere  unless  I  demonstrate  some 
capabilities  to  get  the  people  that  have  money  to  give  it  to  me  to  go  to  the  next  step.  So  the  last 
month  we  conducted  an  exercise  called  ALIX,  Atlantic  Littoral  Exercise,  and  it  was  happening 
anywhere  from  Halifax  all  the  way  to  Batton  Island.  It  was  a  joint  exercise  with  the  interagency 
component  in  it,  and  some  multinational  components.  In  there  I  tried  to  weave  most  of  those 
trends  we  talked  about  earlier,  in  the  different  communities  of  interest,  looking  at  the  areas  where 
we  had  commonalities  and  where  we  needed  translators,  and  we  tried  out  some  of  those 
translators. 


So  we  built  an  operational  architecture  that  provided  me  the  ability  to  have  a  command  and 
control  environment  as  part  of  ALIX  was  operating  at  the  unclassified  level  to  be  able  to  deal 
with  information  with  other  government  departments  on  shipping,  was  operating  at  the  secret 
level,  RELCAN  to  deal  with  NORAD  information  on  recognized  air  picture  and  be  able  to  deal 
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with  task  force  at  seas,  and  I  had  some  specialized  equipment  deployed  there  to  deal  with  IEW. 
So  the  red  part  is  what  we  were  running  purely  at  the  secret,  RELCAN  (releasable  to  Canada)  or 
CAN/US  eyes  only,  the  rest  of  the  environment  was  operating  at  the  releasable  to  For  Official 
Use  Only,  within  Canadian  government.  Next  year  when  we  run  the  same  experiment,  we’re 
going  to  run  most  of  it  at  the  secret  level  with  some  above  secret,  and  we’re  going  to  keep  a 
small  enclave  at  the  unclassified  level.  What  we  did,  we  provided  C2  tools,  battle  management 
tools,  planning  tools  that  were  enabling  people  to  deal  with  electronic  up  orders,  collection 
management  tools  to  deal  with  the  RFI  process,  document  management,  to  be  able  to  deal  with 
the  linking  and  producing  documents,  knowledge  database  about  our  lessons  learned,  imagery 
visualizations,  primarily  one  of  your  products  like  the  JIVE  and  ITS,  so  those  were  the  tools  that 
we  have  in  the  inventory  today  that  are  with  our  warfighters  for  doing  their  job.  We  added  some 
tools,  automation  coalition  tools  for  free  text  were  added,  based  on  commercial  technology, 
expanded  to  support  a  translator  to  C2IEDM.  Imagery  exploitation  the  same  way,  for  both  SAR, 
EO  and  GNTI  again  translating  into  reports  in  C2IEDM.  One  of  the  biggest  tasks  we  had  after 
that  was  to  deal  with  link  analysis.  Both  for  human  and  ESN  purposes  we  were  using  a 
commercial  tool  called  12  and  a  gut  tool  from  the  US  called  Medina,  to  be  able  to  deal  with  ESN 
and  be  able  to  provide  in  C2IEDM,  format  networks,  nodes,  location  and  network  analysis  to  be 
able  to  link  us  back  to  other  people.  And,  keep  the  analytical  side  for  the  all  source  cell 
environment. 


In  order  to  meet  my  joint  requirement,  I  needed  to  be  able  to  start  the  exercise  with  a  recognized 
belligerent  picture,  so  we  built  and  tested  a  MIDB  to  C2IEDM  translator,  and  if  you  think  it’s 
fun,  no  it’s  not.  It’s  doable,  but  it  requires  a  lot  of  subject  matter  expertise  to  do  it,  because  the 
language  of  the  two  is  two  forms  of  English  that  don't  exactly  match  in  the  middle.  We  then 
wanted  to  bring  in  the  recognized  maritime  picture  and  recognized  air  pictures,  and  to  do  that  we 
did  a  bidirectional  interface  with  TDBMS  on  DXM.  We  had  a  NORAD  feed  coming  in  and  that 
link  1  IB  coming  in,  again  with  a  translator  going  into  C2IEDM.  I’ll  show  you  pictures  of  some 
of  those.  In  order  to  show  the  nature  of  the  operation  I  was  into,  we  also  wanted  the  local  air 
picture  so  off  of  a  real  surveillance  radar  it  was  feeding  it  both  the  real-time  on  the  radar  pictures 
at  the  headquarters,  and  another  real-time  for  command  and  control  planning  into  our  C2IEDM 
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environment.  We  then  wanted  to  show  we  could  engage,  so  I  had  a  couple  different  types  of 
shooters,  the  one  that  was  the  biggest  integration  we  did,  our  equivalent  of  your  AFATDS  called 
IFCCS  where  we  integrated  the  fire  support  environment  in  order  to  be  able  to  do  air  missions 
and  ground  missions. 

The  only  part  of  security  we  solved  was  going  from  low  to  high,  so  the  agency  would  be  happy 
with  the  way  we  did  it.  Guarding  coming  back  down  is  still  a  traumatic  event,  and  we  don’t 
know  how  to  do  it  yet. 


So,  to  show  some  of  what  we  did,  we  brought  in  both  the  land  pictures,  the  recognized  local  air 
pictures,  the  unknown  that  came  up  GMTI  and  what  was  coming  off  the  Coast  Guard  and  like  a 
recognized  maritime  picture,  those  were  at  the  unclassified  level.  What’s  different  than  most  of 
the  other  applications  is  the  context  was  preserved.  By  being  able  to  have  each  one  of  those 
sources  create  their  own  overlays,  you  knew  what  came  from  where  and  were  able  to  track  the 
history  of  the  information  like  you  have  today,  to  be  able  to  manage  linkages  in  between  them, 
this  is  the  same  as  that,  or  this  unit  is  part  of  that  network,  so  this  was  one  part  of  it. 
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We  then  were  able  to  come  in  and  integrate  some  of  my  recon  elements  at  the  land  level  and 
have  those  hits  from  a  recon  element,  a  basic  reconnaissance  patrol,  go  back  up  for  targeting 
purposes  to  the  operational  level  of  headquarters  that  was  in  Halifax.  In  Halifax  they  were 
receiving  it  on  GIG  Sam,  it  was  starting  in  the  coyote  reconnaissance  vehicle  equivalent  to  a 
striker,  and  being  translated  seamlessly  all  the  way  to  us  in  seconds,  not  hours. 


And  then  we  dealt  with  the  intelligence  picture  by  being  able  to  create  the  intelligence  collection 
plan,  NEIs,  TEIs,  the  intelligence  taskings,  PIRs  and  IRs,  and  be  able  to  get  the  report  directly 
from  the  shooters,  or  the  sensors  be  able  to  do  it,  we  had  direct  linkage  between  vehicles,  or  fire 
direction  center  and  the  reconnaissance  patrols,  and  we  were,  doing  live  engagements  on  the 
ground. 
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We  went  to  the  SI  of  the  task  group  at  sea.  I  brought  the  unclassified  side  of  it.  We  had  to  strip 
a  fair  amount  of  it,  we  had  a  Canadian  frigate  in  the  middle  of  Grand  Banks,  off  link  1  IB.  They 
sent  us  back  their  recognized  maritime  pictures  within  100  kilometers  of  where  they  were,  and 
we  were  able  to  move  that  back  and  forth.  On  a  different  demo,  in  a  different  setting,  we  can 
show  the  live  feed  coming  in  off  both  an  Aurora,  like  which  is  a  P3  Orion,  feeding  their 
recognized  maritime  pictures  and  recognized  air  pictures  off  link  11B  and  the  same  thing  off  of 
the  DDH.  So  those  things  are  possible.  But  at  one  point  there’s  still  some  translation  issues  that 
we  have  to  get  "right-er".  So  we  need  to  get  the  subject  matter  experts  together.  In  our  case  the 
next  step  is:  sit  a  naval  officer  beside  an  army  officer  so  they  can  get  the  right  language.  There’s 
a  couple  interesting  examples.  It  was  the  first  time  we  were  using  the  P3  Orion  in  land  support 
with  a  land  warfare  group  on  the  ground.  So,  we  tried  a  couple  of  things.  The  first  mission  they 
flew,  the  Orion  thought  he  was  talking  to  a  frigate,  and  the  FAC  on  the  ground  thought  you  were 
talking  to  an  FI 8.  So  from  the  perspective  of  language  and  what  they  had  to  do,  the  aviators  had 
a  problem  with  the  artillery  men  on  the  ground,  oh  how  they  would  pass  targets  and  just  in 
talking.  After  the  first  mission,  with  the  help  of  a  young  air  navigator  who  was  one  of  our 
deployment  in  Afghanistan,  they  get  the  language  down  right,  they  wargamed  it,  and  the  next 
day  they  were  doing  direct  targeting  off  the  Orion,  of  moving  targets  on  the  ground. 

One  of  the  interesting  attempts  we  did  brought  together  a  commercial  predator  and  the  Orion  and 
we  put  them  in  a  head-to-head  competition  on  who  would  pass  the  target  fastest  back  into  the  fire 
direction  center.  The  result  of  hockey  game  is:  Orion  3,  Altair  0.  And  it’s  not  the  technology 
that’s  that  different,  you  know.  The  current  Orion  didn’t  even  have  a  TI  camera,  on  board,  so, 
the  difference  was  the  decision  similar  to  what  the  Marine  Corps  did  in  Iraq.  We  put  a  couple 
ground  liaison  officers  on  board.  When  they  got  the  task  to  look  for  a  gun  battery,  they  found  a 
gun  battery.  On  the  other  side,  the  commercial  people  operating  the  predator  didn’t  know  what  a 
gun  battery  was,  and  so  they  found  me  a  nice  SUV  in  the  middle  of  a  road.  So,  somewhere  in 
there  there’s  something  important  that  must  not  be  missed.  We  in  uniform  have  to  be  part  of 
that  process;  industry  alone  can’t  make  it. 

That’s  coming  to  the  end  of  what  I  have  to  say.  I’m  open  to  questions  and  open  for  sidebar 
discussion  also. 
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Information  And  Global  Integration* 


Col.  Robert  C.  Morris,  US  Army 
Chief,  Space  And  Decision  Superiority  Department 
Joint  Forces  Command 


1.  Purpose 

This  paper  describes  the  concept  of  Information  Operations  that  supports  the  Joint  Operations 
Concepts  (JOpsC),  the  JOpsC  Functional  Concepts,  the  JOpsC  Enabling  Concepts,  and  related 
coalition  and  NATO  concepts  within  the  framework  of  the  future  Joint  Operational  Environment. 
This  effort  by  USJFCOM  J-9  will  support  and  facilitate  the  development  and  production  of 
USSTRATCOM’s  Overarching  Information  Operations  (10)  Concept. 

USJFCOM  delivers  not  only  the  10  inputs  to  the  JOpsC,  but  also  a  summation  of  those  inputs 
creating  a  supporting  joint  10  concept  which  is  referred  to  as  the  “Supporting  10  Concept”  in  this 
document.  As  USSTRATCOM  develops  the  overarching  10  concept  and  architecture, 
USJFCOM  J-9  will  coordinate  and  integrate  its  Supporting  Joint  10  Concept  with  them.  This 
will  lead  to  determining  capabilities  and  requirements  to  execute  all  facets  of  10  in  future 
operations.  It  will  both  support  and  build  from  the  Department  of  Defense  Roadmap  for 
Information  Operations  and  other  relevant  sources.  It  will  apply  the  principles  and  capabilities 
of  the  joint  concept  for  information  operations  to  the  joint  operating,  integrating  and  functional 
concepts. 

2.  Background 

Historically,  service  and  coalition  concepts  evolved  independently,  focused  primarily  on  internal 
service  requirements  with  limited  attention  given  to  true  joint  and  coalition  approaches.  In  an 
effort  to  mitigate  this  problem,  the  Secretary  of  Defense  directed  Joint  Forces  Command  to 
develop  the  JOpsCs  and  related  enabling  concepts.  In  the  area  of  Information  Operations,  the 
Secretary  of  Defense  published  an  10  Roadmap  to  coordinate  the  process  for  Information 
Operations  in  the  near  term.  This  intellectual  capital  must  be  exploited  and  improved  to  achieve 
full  advantage  of  a  vision  for  warfare  that  could  carry  into  the  22d  century. 

Of  some  309  transformational  issues  culled  from  major  DoD  organizations  in  2003,  the 
Department  of  Defense  and  senior  leadership  reduced  the  list  to  18  issues  for  experimentation. 
Information  Operations  was  highlighted  as  one  of  the  critical  areas  to  address. 

In  the  FY2004-2009  Defense  Planning  Guidance,  the  Secretary  of  Defense  designated 
Information  Operations  as  a  core  capability  equal  to  land,  sea,  air  and  special  operations. 
Further,  he  designated  USSTRATCOM  as  the  proponent  for  overarching  10  concept  and 
architecture  for  the  military. 

*  Paper  excerpted  from  the  Information  Operations  PMP  Executive  Summary  Draft  document 
dated  1 7  May,  2004. 
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3.  Information  Operations  -  A  Critical  Need 


Failing  to  properly  develop  a  future  Information  Operations  concept  and  integrate  it  into  joint, 
service,  coalition  and  interagency  future  concepts  may  result  in  slower  reaction  timelines  and 
situations  where  Information  or  other  operations  counteract  and  conflict  with  each  other,  either 
neutralizing  the  desired  effect(s)  or  preventing  the  force  from  achieving  the  desired  effect. 

Independent  or  simply  coordinated  operational  plans  are  no  longer  acceptable  in  an  environment 
where  potential  enemies  can  rapidly  alter  battle  space,  and  where  a  myriad  of  inter-related  social, 
economic,  military,  civil,  and  cultural  aspects  affect  operations  and  the  battle  space  itself. 
Currently  there  are  no  Joint  Information  Operations  and  Information  Assurance  Concepts 
supporting  the  JOpsC. 

4.  Project  Vision 

The  vision  begins  by  using  Joint  Prototypes  and  the  10  Roadmap  as  springboards  for  the  future. 
They  will  be  used  to  design  and  drive  the  Information  Operations  project  focus  and  instill  in  it 
the  purpose,  direction,  and  motivation  required  to  meet  and  exceed  the  demands  of  effects  based 
operations  (EBO)  out  to  2015  and  beyond.  In  implementing  this  vision  all  organizations  must 
operate  using  initiative,  flexibility,  and  agility  at  all  levels.  In  some  cases,  this  may  require 
altering  or  re-engineering  concepts  and  processes. 

This  concept  will  assume  10,  along  with  intelligence  and  space  assets,  to  be  a  core  capability 
equivalent  to  land,  sea,  air,  and  special  operations,  in  accordance  with  Defense  Planning 
Guidance  for  FY  2004-2009.  As  USSTRATCOM  has  been  designated  the  lead  for  development 
and  production  of  the  Overarching  IO  Concept,  the  efforts  by  USJFCOM  J-9  will  support  and 
facilitate  concept  development  and  production,  thus  ensuring  incorporation  within  the  framework 
of  the  future  Joint  Operational  Environment. 

Establishment  of  a  close,  formal  relationship  between  USSTRATCOM/Policy,  Resources  and 
Requirements  and  USJFCOM,  J-9  will  be  through  a  signed  Memorandum  of  Understanding. 
This  will  be  critical  to  capture  synergy  and  ensure  complementary  efforts. 

5.  Project  Objectives 

The  Supporting  Joint  IO  Concept  will  as  a  minimum  focus  on  three  integrated  IO  functions 
across  the  full  spectrum  of  conflict. 

•  IO  will  be  capable  of  deterring,  discouraging,  dissuading,  and  directing  an  adversary, 
thereby  disrupting  his  unity  of  command  and  purpose,  while  preserving  our  own. 

•  IO  will  protect  our  plans  and  misdirect  those  of  the  adversary,  thereby  allowing  our 
forces  to  mass  their  effects  to  maximum  advantage  while  the  adversary  expends  his 
resources  to  little  effect. 
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•  10  will  control  adversarial  communications  and  networks  and  protect  ours,  thereby 

crippling  the  adversary’s  ability  to  direct  an  organized  defense  while  preserving  effective 
command  and  control  of  our  forces. 

The  concept  will  attempt  to  address  these  functions  at  the  operational,  trans-regional,  and 
strategic  levels  while  using  the  five  core  capabilities  of  electronic  warfare  (EW),  psychological 
operations  (PSYOP),  operations  security  (OPSEC),  military  deception  (MILDEC),  and  computer 
network  operations  (CNO).  The  related  activities  of  public  affairs  (PA)  and  civil  military 
operations  (CMO)  will  also  be  addressed  in  this  concept  with  other  supporting  capabilities  such 
as  logistics,  intelligence,  and  space. 

Finally,  this  concept  will  identify  the  requirements  to  integrate  inter-agency  capabilities, 
authorities,  and  functions  with  non-governmental  organizations,  academia,  and  industrial 
capabilities  that  are  as  yet  untapped  resources. 

6.  Links  to  COCOMs,  RCCs,  Services  and  Multi-national  Concepts 

As  approved  by  the  Director,  USJFCOM  J9,  the  future  Supporting  Joint  10  Concept 
development  and  experimentation  will  support  the  global  and  Joint  10  communities.  The 
operational  requirements  and  basic  concepts  for  10  will  be  derived  during  the  front  end  analysis 
(FEA)  of  initial  studies,  lessons  learned,  and  prior  experimentation  conducted  with  the  Joint  and 
JFCOM  Staffs,  Services,  the  Combatant  Commands  (COCOMs),  and  our  multi-national 
Partners.  Specific  links  with  OSD,  Joint  Staff,  STRATCOM’s  JFHQ-IO,  CENTCOM,  SOCOM 
and  EUCOM  will  be  established  to  capture  lessons  learned  from  recent  operations  in  Iraq, 
Afghanistan,  and  elsewhere.  EUCOM  and  JFCOM  staff  support  to  the  approach  is  already 
strong.  Our  link  with  the  NATO  Military  Interoperability  Council  (MIC)  is  an  opportunity  to 
learn  and  incorporate  Coalition  Information  Operations  concepts  and  lesson  learned.  MNIOE 
initiatives  such  as  the  Coalition  and  NATO  Response  Force  Effects  Based  Operations  will  be 
incorporated  in  the  10  concept  development.  These,  in  turn,  are  already  supporting  10  in  the 
JFCOM  MNE  series.  In  our  workshops,  conferences,  and  meetings,  we  will  lay  the  framework 
for  the  integration  of  Service,  other  government  agency,  and  coalition  concepts  within  the  joint 
concept.  This  integration  will  result  in  global  10  concept  development  and  experimentation  and 
thus,  will  refine  the  Joint  10  concept  and  give  greater  insight  to  help  develop  service,  coalition 
(to  include  NATO)  and  other  government  agency  concepts.  This  approach  is  designed  to  support 
STRATCOM’s  development  of  an  over-arching  joint  10  concept  when  they  begin.  In  the 
interim,  STRATCOM  will  be  linked  into  all  program  activities  and  the  products  of  joint  and 
multi-national  experimentation  provided  to  STRATCOM  10  developers.  The  JFCOM  10 
approach  is  also  supporting  the  Army  service  10  concept  development  recently  initiated. 

7.  Technical  Approach 

The  USJFCOM  J-9  project  will  accomplish  its  objectives  using  a  quality  and  functionally  based 
process  through  research  and  implementation.  The  steps  of  this  process  include  identification, 
validation,  verification,  and  documentation  of  conceptual  and  functional  requirements, 
discovery,  hypothesis,  and  validation  experimentation  with  transition  of  deliverables  throughout. 
These  efforts  will  culminate  in  validation  experimentation  of  the  final  concept. 
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The  vehicles  will  be  Front  End  Analysis  (FEA),  wargames,  lessons  learned  and  Limited 
Objective  Experiments  (LOE)  in  FY04  to  develop  the  US  concept  followed  by  a  similar  cycle  to 
support  NATO  concept  development  in  FY05  and  FY06.  The  project  will  be  enhanced  and 
supported  by  limited  experiments  with  a  focus  on  identifying  potential  actionable 
recommendations  and  improvements  to  existing  processes  and  emerging  prototypes  (Standing 
Joint  Force  Task  Force  Headquarters,  Joint  Inter-Agency  Coordination  Group,  etc.)  throughout. 
This  process  will  rapidly  provide  innovations  to  support  hypothesis  testing  of  mature  concepts  as 
well  as  on-going  10  related  actions  in  the  Department  of  Defense  (DoD)  10  Roadmap. 

8.  Integration  Strategy 

The  Supporting  Joint  10  concept  will  be  developed  using  a  disciplined  approach  that  utilizes  a 
concept  development  team,  users  and  Subject  Matter  Experts  (SMEs).  To  achieve  the  desired 
end-state,  the  project  will  define  the  optimum  configuration  in  terms  of  process,  capabilities, 
doctrine,  personnel,  training  and  equipment  with  particular  emphasis  on  integration  of  and  co¬ 
evolution  with  future  Joint,  coalition,  and  inter-agency  future  Information  Operations  concepts. 
The  near-term  end-state  is  to  develop  10  concept  version  1 .0  for  input  to  existing  JOpsC  and 
enabling  concepts  by  1  October  04. 

9.  Experiments 

The  hypotheses  developed  for  the  Supporting  Joint  10  Concept  will  be  tested  and  refined  through 
a  series  of  experiments  prior  to  a  military  utility  assessment.  International  experimentation 
(coalition,  NGO,  corporate)  will  be  carried  out  both  remotely  and  centrally. 

Experimentation  will  commence  in  FY04  with  limited  concept  events  that  address  the  common 
lexicon  of  terms,  cross-walking  concepts,  and  refining  the  overall  approach  for  the  concept. 
These  will  be  supported  by  additional  service,  coalition,  and  inter-agency  wargames  and 
experiments  JFCOM  will  co-sponsor. 

10.  Measures  of  Success 

The  Supporting  Joint  10  Concept  must  demonstrate  the  effectiveness  and  suitability  of  processes 
and  capabilities  to  support  effects  based  operations.  These  include  implementing  future 
operational  and  enabling  concepts  to  plan,  direct,  and  control  the  resources  and  assets  available 
to  achieve  desired  effects.  This  must  include  quantifiable  and  qualifiable  improvements  to  10 
and  the  ability  to  plan,  execute,  and  assess  the  results  of  all  10  concepts  in  an  effects-based 
context.  The  project’s  Critical  Operational  Issue  (COI)  is  “To  what  extent  does  the  new  10 
concept  improve  service,  joint,  coalition  and  inter-agency  10  in  the  future  operational 
environment?”  US  JFCOM,  as  the  Transformation  lead,  has  the  task  of  reporting  the 
effectiveness  of  the  10  concept. 

In  order  to  determine  the  level,  to  which  the  program  answers  the  COI,  the  10  concept  must 
successfully  demonstrate  the  capability  to  satisfy  the  predetermined  Measures  of  Effectiveness 
(MOE)  and  associated  Measures  of  Performance  (MOP).  These  measures  form  the  basis  of  the 
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JFCOM  operational  assessment  of  military  utility  strategy.  The  JFCOM  J9  Analysis  Division 
partnering  with  other  service,  joint,  coalition,  inter-agency  and  non-government  analysis,  will 
perform  both  technical  and  operational  assessments. 

11.  Training 

The  appropriate  level  of  training  will  be  provided  to  personnel  involved  in  all  experiments  to 
ensure  the  results  are  not  distorted  by  a  lack  of  proficiency  in  either  the  concept  or  the  supporting 
systems  and  processes.  Training  will  be  required,  particularly  during  the  experimental  process, 
as  the  concepts,  capabilities,  and  systems  evolve.  The  project  team  will  evaluate  the 
effectiveness  and  efficiency  of  the  training  modules  developed  and  presented.  This  evaluation  is 
conducted  to  determine  whether  incorporation  into  service,  joint,  coalition  and  inter-agency 
training  programs  is  appropriate.  As  concepts  and  experiments  for  10  are  developed,  a  detailed 
training  plan  synchronized  to  applicable  experiments  will  be  developed,  bi-laterally  coordinated, 
and  published  as  an  update  to  the  overall  project  management  plan. 

12.  Participating  Organizations 

As  appropriate,  participating  organizations  will  include  representation  from  all  Services,  joint, 
coalition,  inter-agency,  Non-Government  Organizations  (NGO),  academia  and  corporate 
representatives.  It  will  vary  by  event.  The  co-sponsors  and  10  core  team  will  determine  the 
exact  composition  in  each  event  as  specific  experiments  are  identified  and  integrated  into  the 
project  management  plan. 

13.  Organizational  Approach 

The  USJFCOM  J-9  10  project  will  use  a  series  of  management  layers  and  bodies  to  facilitate 
product  development.  The  adoption  of  such  a  management  structure  ensures  success  for  the 
program 


•  Senior  Steering  Group 

•  Project  Management  Team 

•  10  Concept  Development  Team 

•  10  Core  Management  Team 

•  Interagency  Workshop 

•  MNIOE  Workshop 

Senior  Steering  Group 

The  Senior  Steering  Group  (SSG)  will  be  composed  of  the  sponsoring  Regional  Combatant 
Commands  (RCCs),  Functional  Component  Commands  (FCCs)  and  Senior  Mentors. 
Responsibilities  will  be  to  provide  program  direction  to  ensure  the  10  concept  remains  properly 
focused  and  evolve  to  support  future  operational  capabilities  required. 

This  group  is  briefed  bi-annually  or  as  required  to  provide  senior  level  guidance  and  resolve 
issues  involving  funding,  functionality,  and  competing  RCC,  FCC,  and  service  requirements.  In 
addition,  this  group  will  receive  quarterly  status  reports  from  the  Project  Manager. 
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Project  Management  Team 

The  10  Concept  will  be  lead  by  a  designated,  full-time  Project  Manager  (PM)  and  a  designated, 
full-time  Deputy  Program  Manager  (DPM).  They  will  both  work  directly  for  the  JFCOM  J9 
Chief,  Space  and  Decision  Superiority. 

The  Project  Managers  (PM/DPM)  will  have  overall  responsibility  for  project  budget,  schedule, 
and  performance,  as  well  as  overall  responsibility  for  programmatic  coordination  activities  of  the 
program.  They  will  be  the  primary  interface  with  core  management,  technical,  experimentation, 
evaluation,  modeling  and  simulation,  prototype  and  operational  participants  as  well  as  the 
Services  and  external  organizations. 

The  PMs  will  ensure  coordination  between  concept  developers,  partners  and  users.  It  will  be 
responsible  for  ensuring  consistency  between  the  standards  adopted  for  the  10  concept  and  those 
in  current  JOpsC  Operational  and  Enabling  concepts  as  well  as  those  under  development. 

Concept  Development  Team 

The  10  Concept  Development  Team  (CDT)  will  be  comprised  of  Subject  Matter  Experts,  Action 
Officers  from  participating  organizations  and  others  responsible  for  success  of  the  10  Concept. 
Composition  will  be  developed  based  on  project  plan  coordination  and  requirements,  and  then 
adjusted  as  required  through  project  execution. 

The  CDT  will  be  responsible  for  day-to-day  operations  in  the  development,  support  and 
execution  of  the  project  plan,  to  include  all  experimentation  and  analysis.  This  group  will  be 
responsible  for  the  successful  design,  development,  coordination  and  execution  of  the  project 
from  inception  through  concept  development  and  experimentation  to  transition.  The  CDT  will 
provide  inputs,  comments  and  reports  to  the  Project  Manager  as  directed. 

10  Core  Management  Team 

I 

The  10  Core  Management  Team  is  an  internal  US  JFCOM  body  of  twenty- five  Action  Officers 
responsible  for  10  related  activities  within  the  Unified  Command.  USJFCOM  J9  Space  and 
Decision  Superiority  and  the  J35,  Chief  of  Future  Operations  will  co-chair  the  group.  The 
mission  is  to  share  information  for  better  situation  awareness  of  short-term  and  long-term  related 
10  activities.  The  10  Core  Management  Team  will  also  serve  as  a  coordination  body  for 
feedback  on  10  concept  development  and  experimentation,  supporting  issues,  experiments  and 
actions.  They  will  meet  on  a  quarterly  basis. 

Interagency  Workshop 

10  is  a  constant  challenge  of  integration,  coordination,  and  synchronization,  especially  for 
interagency  action  and  feedback.  USFJCOM  J9  10  Project  Management  Team  will  work 
through  CJCS,  J39/DDGO  to  host  an  Interagency  Workshop.  This  forum  will  serve  as  a  vehicle 
for  interagency  collaboration,  coordination,  and  integration  of  Joint  10  concepts,  National  and 
Military  Policy,  and  Rules  of  Engagement  that  will  impact  10. 
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Multi-National  10  Experiment  (MNIOE)  Workshop 

USJFCOM  J9  has  achieved  great  success  with  multi-national  (MN)  participation  and  continuous 
engagements  through  MNIO  initiatives  and  workshops.  Our  link  with  the  Military 
Interoperability  Council  (MIC)  provides  an  excellent  opportunity  to  learn  and  incorporate 
Coalition  Information  Operations  concepts  and  lesson  learned.  MNIOE  initiatives  such  as  the 
Coalition  and  NATO  Response  Force  Effects  Based  Operations  will  be  incorporated  in  the  10 
concept  development.  These,  in  turn,  are  already  supporting  10  in  the  JFCOM  Multi  National 
Experiment  series.  It  can  be  expected  that  a  derivative  of  the  US  National  10  Concept  will  be 
adopted  by  our  allies. 

14.  Deliverables 

Concept  Version  1.0  -  Describes  and  scopes  a  specific  future  warfighting  problem  and 
potential  solutions. 

The  purpose  of  the  first  version  is  to  (1)  identify  novel  systems,  concepts,  organizational 
structures,  and  technologies  as  potential  solutions  to  specified  warfighting  problems,  (2) 
provide  a  framework  for  Actionable  Recommendations,  Functional  Concepts,  and 
Transformation  Roadmaps,  and  (3)  provide  a  conceptual  and  capabilities  framework  for 
further  concept  refinement  and  higher  fidelity  experimentation. 

It  will  be  composed  of  a  description  of  the  operational  environment,  identification  of 
future  military  problem  to  be  solved,  proposed  solution(s),  required  tasks,  required 
capabilities,  and  examples  of  ideas  in  action. 

Version  1.0  will  be  derived  from  discovery  experimentation,  lessons  learned  from  current 
and  recent  real  world  operations,  and  historical  analysis.  Discovery  experimentation  will 
typically  be  conducted  as  a  low  level  of  fidelity  (seminars,  table  top  wargames,  etc.)  This 
will  include  the  staffing  of  ideas  across  the  Joint  community. 

Concept  Version  2.0  -  Presents  an  experimentally  refined  solution  set  to  the  identified 
warfighting  problem.  Also,  sets  conditions  for  follow-on  high  fidelity  experimental 
assessment. 

The  purpose  of  the  second  version  is  to  (1)  support  the  development  of  actionable 
recommendations  and  transformation  change  packages  through  experimentally  refined 
hypotheses,  (2)  provide  experimentally  refined  capabilities  in  support  of  Functional 
Concept  and  Transformation  Roadmap  development,  and  (3)  set  the  stage  for  follow-on 
high  fidelity  hypothesis  assessment  experimentation. 

It  will  be  composed  of  version  1.0  plus  the  following:  experimentally  assessed 
statements  of  cause  and  effect  relationships  between  the  identified  military  problem, 
proposed  solution,  and  required  capabilities  (with  metrics);  refined  identification  of  how 
to  achieve  required  capabilities;  the  resolution  and  details  needed  to  immediately  start 
prototyping  the  effort,  if  directed;  and  the  associated  CONOPS  for  specific  scenario(s). 
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Version  2.0  will  be  derived  from  hypothesis  refinement  experimentation,  lessons  learned 
from  current  and  recent  and  real  world  operations,  and  historical  analysis.  Hypothesis 
refinement  experimentation  will  typically  be  conducted  at  a  medium  level  of  fidelity  (i.e. 
M&S  supported  wargames). 

Concept  Version  3.0  -  Provides  experimentally  assessed  solutions  and  required 
capabilities. 

The  purpose  of  the  third  version  is  to  (1)  support  the  development  of  actionable 
recommendations  and  transformation  change  packages  through  experimentally  assessed 
cause  and  effect  relationships  between  military  problems  and  identified  capabilities,  (2) 
identify  high  value  potential  prototype  efforts,  and  (3)  provide  experimentally  assessed 
capabilities  in  support  of  Functional  Concept  and  Transformation  Roadmap  development. 

It  will  be  composed  of  version  2.0  plus  the  following:  experimentally  assessed 
statements  of  cause  and  effect  relationships  between  the  identified  military  problem, 
proposed  solution,  and  required  capabilities  (with  metrics);  refined  identification  of  how 
to  achieve  required  capabilities;  the  resolution  and  details  needed  to  immediately  start 
prototyping  effort,  if  directed;  and  associated  CONOPS  for  specific  scenario(s). 

Version  3.0  will  be  derived  from  hypothesis  assessment  experimentation,  lessons  learned 
from  recent  and  current  real  world  operations,  and  historical  analysis.  Hypothesis 
assessment  experimentation  is  typically  conducted  at  a  high  level  of  fidelity  (lab  settings, 
field  experiments,  etc.)  to  explore  alternative  cause  and  effect  patterns  and  sets  of 
limiting  conditions. 

15.  Organization  and  Staffing 

Overall  responsibility  for  management  of  the  Supporting  Joint  10  Concept  will  reside  with 
JFCOM  J9,  Space  and  Decision  Superiority  Department.  Key  to  IO  concept  development  is  the 
temporary  assignment  of  functional  and  technical  staffs  from  internal  and  external  to  JFCOM  to 
jump  start  the  concept  development  process.  This  will  be  necessary  until  full-time  positions  are 
filled  with  personnel  to  provide  the  critical  institutional  knowledge  and  subject  matter  expertise. 
With  strong  relationships  and  participation  from  all  Services,  joint,  coalition,  inter-agency,  and 
Non-Government  Organizations  representatives,  the  IO  Concept  Development  Team  is  well- 
positioned  to  successfully  develop  and  integrate  the  conceptual  framework  for  Information 
Operations  to  support  the  future  force.  The  organization  framework  and  proposed  staff  expertise 
is  shown  in  figure  1 . 

Initially,  this  organization  will  be  small  and  draw  upon  the  resources  of  other  Divisions. 
However,  upon  completion  of  JOpsC  prototype  and  enabling  Concepts  integration, 
approximately  1  OCT  04,  the  IO  Cell  should  become  robust  and  representative  of  every 
capability  of  IO,  while  also  possessing  liaisons  from  related  activities,  and  critical  interagency 
players. 
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16.  Equipment  and  Facilities 


It  is  essential  that  equipment  and  facilities  be  taken  into  account,  not  only  workspace  and 
equipment  requirements  for  personnel,  but  also  the  communications  and  networks  requirements 
for  experimentation.  Workspace  and  seating  requirements  internal  and  external  to  a  Special 
Compartmentalized  Information  Facility  (SCIF)  and  a  Special  Technical  Operations  facility 
(STO)  will  be  requested  for  temporary  and  permanent  personnel.  In  addition,  equipment 
supporting  Joint  Warfighting  Intelligence  and  Communications  System  (JWICS),  Joint 
Interactive  Analysis  and  Planning  Capability  (JIAPC),  Special  Access  Programs  (SAP), 
Restricted  Handling  Caveats,  and  Information  Warfare  Planning  Capability  (IWPC)  are  required 
for  experimentation.  The  assessment  by  Systems  of  Systems  Analysis  (SOSA)  staff  also  will  be 
required  to  meet  anticipated  networks  and  infrastructure  requirements. 

Further,  it  should  be  expected  that  the  10  Staff  will  expand  and  contract  as  experts  external  to  the 
command  are  brought  in  temporarily  to  achieve  specific  objectives  associated  with  concept 
development.  While  much  of  the  effort  will  be  accomplished  “virtually”  by  teleconferencing  and 
internet,  brainstorming  sessions  must  still  be  accomplished  through  face-to-face  meetings. 
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FIGURE  1  -  Organizational  Framework  and  Staffing  Requirements 
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17.  Project  Timeline 


The  overall  USJFCOM  J-9  project  will  be  a  36-month  effort.  The  first  12  months  will  consist  of 
detailed  Front  End  Analysis  (FEA)  supported  by  discovery  experimentation  and  developing  the 
over-arching  joint  concept.  It  will  accelerate  opportunities  to  accelerate  joint,  service,  coalition 
and  inter-agency  future  concepts.  Hypothesis  development,  testing,  and  validation  during  the 
following  24  months  (FY05  and  FY06)  will  culminate  in  transition  to  prototyping.  Figure  2 
shows  the  proposed  schedule  by  phase  with  planned  meetings/collaboration,  participation  in  key 
events,  and  project  deliverables. 
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Global  Information  Integration  and  Decision  (GIID)  Portfolio 

Peter  M.  Trask 
Christine  Salamacha 
Michael  Cramer 

The  Johns  Hopkins  University  Applied  Physics  Laboratory 

The  Global  Information  Integration  and  Decision  (GIID)  Portfolio  is  a  multi-year  initiative  to 
demonstrate  and  transition  an  integrated  portfolio  of  capabilities  in  strategic  and  national 
command  and  control  (C2),  consistent  with  DoD’s  transformation  to  net-centric  operations  and 
warfare.  Working  with  established  programs  and  new  initiatives,  the  Portfolio  will  provide 
cross-domain  orchestrated  services  based  on  U.S.  Strategic  Command  (USSTRATCOM)  Global 
C2  needs.  Each  program  and  initiative  will  provide  web-based  services  and  expose  data  in  a 
“services  oriented  architecture.”  The  Portfolio  will  leverage  DoD’s  net-centric  core  services. 

The  GIID  Portfolio  initiative  will  provide  incentives  for  legacy  programs  to  develop  net-centric 
implementations.  It  will  establish  an  ontology,  taxonomy,  and  data  model  for  the  missile 
warning  and  defense  community  and  will  extend  them  to  other  communities  in  subsequent  years. 
In  the  short  term,  the  GIID  architecture  will  require  legacy  systems  to  expose  data  and  services, 
while  they  maintain  parts  of  their  legacy  system  architectures.  The  long  term  goal  is  an 
architecture  where  new  developments  are  consistent  with  the  Global  Information  Grid  (GIG) 
systems  engineering  and  net-centric  data  strategy. 

The  principal  sponsors  of  the  GIID  portfolio  are  Office  of  the  Assistant  Secretary  of  Defense, 
Networks  and  Information  Integration  and  USSTRATCOM.  Programs  in  the  initial  GIID 
portfolio  include: 

•  Command  and  Control  of  Ballistic  Missile  Capability  (C2BMC) 

•  Combatant  Commander’s  Integrated  C2  System  (CCIC2S) 

•  Defense  Strategic  Integrated  Decision  Environment  (DSIDE) 

•  Fused  Battlespace  View  (FBV) 

The  authors  would  like  to  acknowledge  the  contributions  of  Tom  McNamara  and  Janet  Spedden 
from  the  Johns  Hopkins  University  Applied  Physics  Laboratory  for  definition  of  the  GIID 
Portfolio.  Other  organizations  making  significant  contributions  to  definition  of  the  GIID 
Portfolio  are  Lockheed  Martin,  The  MITRE  Corporation,  FGM,  Inc.,  National  Security  Research 
(NSR),  and  the  Defense  Information  Systems  Agency  (DISA). 
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Global  Information  Integration 
and  Decision  (GIID)  Portfolio 


Sixth  Annual  ONR/CADRC 
Decision  Support  Workshop 


Peter  M.  Trask 

The  Johns  Hopkins  University 
Applied  Physics  Laboratory 

9  September  2004 


Outline 


GIID  Portfolio 

•  Expedient  Community  of  Interest  (ECOI) 
Services 
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GIID  Portfolio  Overview 


•  A  multi-year  portfolio  plan 

4  Funded  in  FY05  by  Horizontal  Fusion 

•  Focus  on  Strategic  and  National  C2 

4  Fill  gaps  in  selected  mission  threads 
4  Identify  and  resolve  overlaps 

•  Support  DoD  transformation  to  NCOW 

4  Consistent  with  DoD  Net*centric  data  strategy 
4  Leverage  NCES 

•  Evolve  legacy  systems  to  net-centric  SOA 
4  Publish  authoritative  data 

4  Expose  functions  as  web  services 


GIID  Stakeholders 


•  Portfolio  sponsors 
4  OASD  (Nil)  C2  Policy 
4  USSTRATCOM 


•  Program  sponsors 
4  USSTRATCOM  - 
4  MDA 
4  USAF,  ESC 
4  NAVAIR 


D-SIDE,  FBV,  l-SPAN 

C2BMC 

CCIC2S 

Mobile  Command  Element 
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iffti I  The  GIID  Portfolio  Approach 

% 


*  Define  global  C2  capabilities 
required  for  strategic  reference 
mission(s)  &  scenarios 

*  Establish  a  'portfolio1  of  services 
from  existing  C2  programs  of 
record  that  fulfill  defined 
capabilities 

4  Avoids  stovepipe  focus 
4  Shifts  focus  from  programs/ 
platforms  to  capabilities 

*  Leverage  Net-Centric  initiatives 
(e.g.  GIGt  NCES) 

*  Capture  portfolio  lessons  into 
guidance,  policy,  doctrine, 
standards  for  broader  domain 
application 

*  Requires  strong  warfighter 
support  to  advocate  and  support 
portfolio  efforts 


strategic  reference 


REQUIRED  DAPS 

#1 


FY07 


FT  Do 


FY05 


GAPS 


Services 


GIID  Architecture  Evolution 


*  Objective:  Develop  an  architectural  approach  leveraging 
NCES  and  SOA  for  integration  of  services  provided  by  the 
various  C2  programs. 

*  Short-Term  Approach: 

4  Examine  legacy  system  architectures  to  find  opportunities  to 
integrate  at  multiple  levels  and  expose  services 
4  Expose  information  based  on  shared  ontology 
-  Wrappers,  XML,  mefa-dafa  tagging 
4  Support  “post  before  process” 

*  Long-Term  Approach:  Evolve  to  an  architecture  where 
independent  development  is  consistent  with  GIG  systems 
engineering 

*  Establish  ontology  and  data  model  to  provide  consistent 
basis  of  communication 
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GIID  HF05  Mission  Thread  & 

Selected  Services 


Activate  Expedient  Communities  of  Interest 
Discover  Expedient  Communities  of  Interest 


Use  Expedient  Comm  unities  of  Interest 

Expedient 
Communities 
of  Interest 


Text  Presentation 

Table  Presentation 

■001 

COA 

Geospatial  Presentation 

Mission  Analysis  Service 
Tasking  and  Orders  Management  Service 

Course  of  Action 
Planning 


Missile  Defense 


GIID  HF05  Services 


Blue  Force  Satellite  Status/Readiness 

IMD 

Warning  Asset  (Radars+IR)  Sts  &  Readiness 

Missile  Launch  Warning  (ITW/AA) 

Missile  Launch  Warning  (Non-ITW/AA) 

Missile  Warning/Missile  Defense  Integration 

BM  OP  Plan  Data 

BM  Engagement  Status  Reports 

BM  Prioritized  Defended  Asset  Lists 

NO  RAD  Air  Tracks 

Post  Before  Process 
(for  IMD) 

Non-NORAD  Air  T racks 

Space  Tracks 

Text,  Table,  &  Geospatial  ODI  Display 

GIID  MARS  Portal 

Mission  Analysis  Service 

COA  Development 
Integration  w/  GS  Plans 

Tasking  and  Orders  Management  Service 

Activate  Expedient  Communities  of  Interest 

ECOI 

Discover  Expedient  Communities  of  Interest 

Use  Expedient  Communities  of  Interest 
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Outline 


•  GIID  Portfolio 

0  •  Expedient  Community  of  Interest  (ECOI) 
Services 
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Expedient 


Institutional 


Types  of  COIs* 


Tactically  driven. 
Implied  authority, 
Formal  processes 
modified  for  need, 
Relatively  many 
entities 

(e.g.,  New  Imagery 
Analysis  capability  for 
Damage  Assessment) 

Tactically  dnvSTl>ii^ 
Derived  authority. 

Ad  hoc  processes 
modified  for  need, 
Many  many 
entities 

(e.g.,  Forward  deployed  JTF 
planning  New  Threat  .. 

Res  ponse 

Explicitly  recognized, 
Longer  term, 

More  formalized 
processes  based 
on  span  of  control, 
Relatively  few  entities 
(e.g.,  PSAs  such  as 
Logistics) 

Explicitly  or  implicitly 
recognized, 

Longer  term  but 
priority  driven, 
Blended  processes 
resulting  from 
agreements 
(e.g.,  JS  area  such  as 
Battlespace  Awareness) 

CO/  Initialization 
COI  Participation 
COI  Discovery 
COt  Transition 
COt  Termination 
COt  Authority 
COt  Permissions 
COt  Reporting 
\COt  Span  of  Controt 


Functional  Cross -Functional 

‘Identified  in  DoD  Net-Centric  Data  Strategy 


Expedient  COI  Services 


*  ECOI  services  enables  expedient  operational 
Communities  of  Interest  (COIs)  to  be  formed 
quickly  in  response  to  crisis  situations 

•  ECOI  services  include: 

4  Quickly  establishes  COI  membership, 
relationships,  roles,  business  rules  to  meet  the 
demands  of  the  moment 

-  Emphasis  on  crisis  response ,  mission-focused  support 

4  Populates  a  customized  COI  environment  (views, 
tools) 

4  Leverages  standing  COIs  and  established  tasking 
relationships 

-  Use  of  COI  templates  or  patterns 
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Expedient  COI  Services 
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f  ffil  Web  Service  Orchestration  in  the  GIID 

*  Encode  Business  Rules  and  Workflow 

■  Allow  run-time  variations  based  on  operator  actions, 
alerts,  or  changes  in  environment 

-  Control  Interactions  between  Web  Services 

*  Execute  Asynchronous  and  Long-Running 
Processes 

*  Operate  in  the  context  of  an  Orchestration  Engine 

*  Example: 

4  Aggregate  data  from  multiple  web  services 

4  Transform,  e.g,  changes  in  units,  or  map  between 
schemas 

4  Provide  value-added  web  service  or  display 


Notional  GIID  Orchestration 

ECOI  Example 
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GIID  HF05  Portfolio  Summary 


•  Focus  is  Strategic  and  National  C2  enablers  and 
net-centric  transformation 

■  Missile  Warning/  Defense  integration  at  the  data  level 

■  Maintain  link  to  Global  Strike  via  coordinated  COA 
planning 

•  Capabilities  met  through  services  offered  by  legacy 
programs 

■  Publish  legacy  data 

■  Legacy  C2  functions/applications  exposed  as  services 

■  17  Services  from  6  PORs 

•  Key  Stakeholders: 

OASD  (Nil),  USSTRATCOM,  MDA,  USAF  ESC,  NAVAIR 
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Sixth  Annual  ONR I CADRC 
Decision-Support  Workshop 

“Interoperability  Levels” 

Dr.  Peter  Bahrs,  Distinguished  Engineer 
Dr.  Chris  Codella,  Deputy  CTO 

September  8-9,  2004,  Quantico,  Virginia 
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Introduction  -  Best  Practices 


This  presentation  is  based  on  many  years  of  experience  with  1000s 
of  customer  projects 

Interoperability  is  mainstream  in  other  industries;  evidenced  by 
partnerships,  standards  development  and  COTS  maturity 

Interoperability  is: 

“Enabling  business,  systems,  and  people  to  share  development 
artifacts,  runtime  information  and  common  operations.” 

Open  Standards  are  a  key  to  successful  interoperability 

Successful  open  standards  are  those  that  are  widely  accepted 
across  industries  and  have  significant  commercial  investment 
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Introduction  -  Industry  Adoption  of  Open  Standards 


Applications 


Operating 

System 


I  lardware 


client  /  seivei 
1  47to 


Applications 


M  tddteware 
J2EE 
XML 
W* 
Duabaae 
System*  MgL 


App  L  Lc-ilt  ion  I 
System  afS; 


M  iddlcwan 
Web  Service^ 
BP  EL 
Simulalioji 
[nieiJaii*n 
Security 


OS 

Linux 


App  Beast 
System  ofSy&h 
"  Model  Dri 


ions  M  ixle-LLrijj. 

tana 

App  Beat  Lons 


M  iddl-evi 
SOA 
Ehtapn 
Serviee 
Other 
Industries 


►  »iS 


OS 

Linux 

IPV6 


I  lardware 


i 

INTEROPERABILITY  &  FLEXIBILITY 


Virtualization 

Grid 

I  lardwarc 
on  derrand 

... 

-  HIGH 
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Introduction  -  Interoperability  Challenges 

Can  I  react  quickly  enough  to  opportunities  or  threats  to  my 
environment? 

Can  I  create  new  mission  capabilities  from  my  existing 
systems? 

Can  users  react  in  real-time  to  the  most  recent  information? 

Can  I  easily  access  information  anytime,  anywhere  with  my 
choice  of  device? 

Are  my  business  operations  integrated  end-to-end  for 
optimal  efficiency? 

Can  I  decrease  expense  while  providing  more  function? 


AH  Rights  Reserved 
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Introduction  -  The  Next  Internet  Protocol  Stack 


Person 


Business 

Process 


Computer 


Network 


Application 


Presentation 


Session 


Transport 


Network 


Data  Link 


Physical 

Tannenb-aum,  10B1 


WS-Trust 
WS-T  ransactions 

WS-Policy 

BPEL 

SOAP 

XML 

HTML 

HTTP 


"1935 


TCP/IP 


A  New  Programming 
model  and  computing 
platform  is  emerging 

Based  on  collections 
of  web  services  (not 
networks  of 
computers) 

Complex  sets  of 
distributed  services 
will  appear  as  though 
they  exist  and  run  on  a 
single  "machine"  -  a 
virtual  computer 

A  runtime  environment 
will  be  required  to 
support  the  semantics 
and  expectations 
associated  with  this 
new  programming 
model 
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Anatomy  of  a  System 

* 


V-  '  j;RFID 

SensorWctuator  centric 


Warfighter  centric 


It 

\ 


Communications 

centric 


Collaboration  centric 


Network  centric 


rver  centric 


Determinism 

Nodal  Complexity 

Lifecycle 

Real  Time 

■Sensor 

Requirements 

Soft  Real  Time 

Actuator 

Architecture 

Time  Sharing 

Control  system 

Smulation 

Radio 

Design 

Information 

Workstation 

Development 

Message  Router 

■Server 

Build 

Pub  /Sub 

Broker 

■Testing 

Service  Bus 

Cluster 

Standards 

Transformation 

Integration 

Federation 

Processing 

Classification 

Process  Modeling 

Security 

Awareness 

Workflow 

Policy 

Autonomic 

Event  analysis 

Transactional 

Culture 

Provisioning 

Operations 

Non  Functional: 

Deployment 

Performance 

Service  Oriented 

Change 

Security 

Publish 

Monitoring 

Throughput 

Discover 

Management 

QOS 

Access 

Recovery 

SLA 

Users 

Volumes 

All  Rights  Reserved 
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Anatomy  of  an  IT  system  (cont.) 


Shared 


Example: 

Mobile 

Multiple  networks 
Hardware,  OS,  Middle' 
Security  -  hardware 
Dynamic  network 
Dynamic  hardware 


Applications 
plication,  Data 


Information  Asynchronous 
rules 


-Data  Access 


-Service  Access 


System  Access 


User  Access 
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Level  1  -  network  connectivity 


System  A  System  B 

Physical:  Ethernet,  Token  Ring,  Router.  Bridge,  etc. 


AH  Rights  Reserved 
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Level  2  -  network  protocol 


System  A  System  B 

Protocol:  TCP/IP,  802.1  1.  NETBIOS,  Open  Standards,  etc. 


All  Rights  Reserved 
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Level  3  -  static  discovery 


1  know  the  name  of  System  B 


access 


System  A 


System  B 


Names  are  static,  hard  coded,  finite,  not  scalable. 


All  FUghLs-  Reserved 
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Level  4  -  dynamic  discovery 


Discover  systems 


Ifoopd  the  name  of  System  B  and  access  it. 


f  ^  ^  -  s. 

/  si 

access 


System  A 


System  B 


Names  are  dynamic,  lookup  performed,  name  or  location  found,  scalable.  Open  Standards. 
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Level  5  -  guaranteed  delivery 


When  I  send  X  Y2,  it  is  guaranteed  to  get  there. 


Logged,  traceable,  transactional.  Open  Standards. 


AS  Rights  Reserved 
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Level  6  -  information 


When  1  send  XYZ ,  System  B  understands  and  expects  it. 


System  A 


System  B 


Industry  data  models,  schemas,  Open  Standards. 
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Level  7  -  enterprise  service  bus 


Isend  information  via  another  system. 


ESB 


System  A 


System  B 


Open  Standards,  SOA,  guaranteed  delivery,  multiple  protocols,  heterogeneous  systems. 


AH  Rights  Reserved 
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Level  9  -  lifecycle 


Two  systems  share:  formal  models,  simulation, 
code,  artifacts,  scripts,  testing. 

Highest  level  of  reuse. 


Tools,  Artifacts,  Models 


V 

lwoJptafl.il 

Modal  iivg 

m 

V 

OrcJMStr&tlcH 


Deploy  urie ill 

Urn*. 

Web  SarvJcasJ 

"  =4lrr 


Mai! 


uage-maM 

C*inp*iw-iul 

ManWj 
*PP  Myint 


System  A 


System  B 


Open  Standards,  J2EE,  WSDL,  UML2.  MDA. 

f,7  X 

All  Rig  h  is  Re  zb  rve  d 
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Level  A  -  Visual 


System  Access 


Presentation 

Services 


System  A 


System  B 


Portals,  CuVPaste,  iBIn,  Visuals.  Caching 


115 


I  IBM  Software 


Level  B  -  Data 


1 

r 

□ 

Data 

Services 

5 

System  A 


System  B 


Models,  Joining,  Federation,  Integration,  Warehousing,  Archive,  Information. 


All  Rights  Received 
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Level  C  -  Services 


Services  i  r 


System  A 


System  B 


Service  Oriented,  Function,  Logic,  Rules,  Policy 
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All  Rig  hit  Reserved 
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Level  E  -  Security 


Pervasive  across  all  levels 
of  interoperability 

Each  level  specifies 
security  characteristics 

i.e.  Level  4.1  or  4.2 


System  N 


AJI  Rights  Reserved 
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Interoperability  Feasibility  Assessment 
r 


Level 

Arch  1 

Arch  2 

Description 

1 

X 

X 

Network  connectivity:  Networked  machines;  wire/wireless 

2 

Network  protocol:  TCP/IP,  IPV6 

3 

X 

Static  discovery:  other  systems  known  statically 

4 

X 

Dynamic  discovery:  other  systems  found  dynamically 

5 

Guaranteed  delivery::  transfer  guaranteed;  traceable 

6 

X 

Information:  Transmit  industry  standards  data  models 

7 

Enterprise  Service:  Bus:  broker,  route,  transform,  pub/sub,  filter. 

8 

X 

Mega  System:  one  to  many  system  access 

9 

X 

X 

Lifecycle:  Extends  beyond  runtime  to  build  &  manage  integration 

A 

X 

Visual:  thin,  thick,  presentation 

B 

Data:  integrator,  federation,  warehouse 

G 

X 

Service:  functional,  logic,  rules 

D 

Operations  :  management,  platform,  recovery 

E 

X 

Security:  multi  level,  rules 

K 


All  FLighLs-  Retarv-ed 
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Interoperability  Feasibility  Assessment  (cont.) 


Each  candidate  system  to  be  considered  for  inclusion  in  an 
interoperability  transformation  must  provide  a  feasibility 
inventory 

Includes  people,  business  and  technology  items 

The  more  that  is  known  about  a  system’s  usage  and 
development,  the  easier  the  integration  estimation 

Not  all  systems  will  become  interoperable... 

Cost  limitation 
Skills  availability 
Time 


24  I  Al  Rig  his  Resarved 
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Interoperability  Feasibility  Assessment  (cont.) 


Open  Standards  Supported 
External  Functional  APIs 
External  Data  SQL 
External  Data  Models 
Transaction  Boundaries 
Error  Logging  and  Handling 
Security  Contexts 
Data  Throughput 
Caching 


Operating  System 
Dependencies 

Hardware  Platform 
Dependencies 

Network  Dependencies 

3rd  Party  Dependencies 

Tools 

Proprietary  Systems 
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Interoperability  Feasibility  Inventory  (cont.) 


SME  Usage  Skills 
SME  Development  Skills 
Modeling  Artifacts 
Design  Artifacts 
Development  Methods 
Coding  Standards 
Build  Processes 
Testing  Processes 
Deployment  Processes 


Performance  per  invocation 

Configuration  management 

Operational  Procedures 

Change  Management 
Processes 

Recovery  /  Restart  Process 

Systems  Management 
Processes 

Release  Schedule 

Security  Clearances 
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Summary  -  Service  Oriented  Architecture  View 
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Thank  You 


bahrs@us.ibm.com 
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Interoperability  Cost  Estimation 

Sixth  Annual  ONR/CADRC  Decision  Support  Workshop 

September  2004 

Conrad  W.  Strack,  Ph.D. 

cstrack@csci-va.com 

703-866-4000 


Family  of  Systems  defined  by  platform  types  in  architecture: 

•  Goal  is  layered  defense  against  missile  attack 

•  Family  already  exists:  Aegis,  Patriot,  AW  ACS,  TPS-59... 


Interoperability  is  sharing  data  to  improve  performance : 

•  often  “fire-control  quality”,  low  latency,  frequent  update 

•  sensor  netting,  precision  cueing  and  integrated  layered  defense 

•  sensor-shooter  link  to  exploit  sensor  and  interceptor  range 

Interoperability  can  help  avoid  serious  tactical  problems : 

•  duplicate  tracks:  ID  loss,  interceptor  wastage,  leakage 

•  small  defended  footprint  many  defenders,  small  keepout  range 
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Can  Avoid  This  Track  Confusion 

■■■■■■■■III 


B  CD 


4014 

3057 

3132 

2315 

1632 

3042 

4007 

4010 

2267 

1676 

1646 

3035 

4020 


2270 

J645 

3062 

3047 


2316 

3043 

4021 
1654 

4022 
3040 
3033 
1570 
3037 
2302 
1570 
2242 


4012 
2312 

1652 

4013 

1653 
1722 
4027 
1716 

1721 

1722 
3064 
3066 
4031 

1712 
3031 
3057 

1713 


14  minutes 
from  a  recent 
Link  16  track 
history 

The  average 
track  lifetime  is 
2  minutes . 
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Key  Enabling  Concept  1:  Gridlock 

^■■■■^■■■■■■■■■111 


Gridlock  means  all  units  know  own  position,  horizon,  north: 

•  gridlock  enables  precise  sensor  registration 

•  precise  sensor  registration  enables  cueing, 
avoids  duplicates,  and  allows  composite  tracks 


Ground 

Truth 


Sensor  1, 
position  error 


Sensor  2, 
direction  error 

n — 


Sensor  3, 

position  &  direction  errors y 


Without  gridlock, 

3  apparent  tracks,  all  wrong 


With  gridlock,  1  single 
composite  correct  track 
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Key  Enabling  Concept  2:  Cueing 

hhhhhmni 


•  Precise  cueing  tells  sensors  &  weapons 
where  to  look  and  thereby  increases  range. 


•  Without  cues,  sensor  energy  is 
spread  over  entire  field  of  regard. 

•  Precise  cues  allow  sensor  to  focus 
energy  and  thereby  extend  range. 

•  Increased  sensor  range  allows 
earlier  tracks  &  earlier  intercepts. 
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'osite  Track 

II 


A  composite  track  is  more  precise 
than  any  single  sensor’s  track. 

Each  sensor  has  an  error  ellipse 
of  target  uncertainty. 


Intersecting  ellipses  reduce 
position  uncertainty  and 
allow  an  earlier  intercept. 


rger  uncertainty 
of  local  tracks 


small  uncertainty 
of  composite  track 


Composite  tracks  are  always 
at  least  as  good  as  local  tracks. 
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Interoperability  Improves  Tracks  &  Results 

I 


Composite  Tracks  Are  Always 
Better  Than  Individual  Tracks 


Composite  Tracks  Persist 


When  Single  Sensors  Fail 


Composite  Tracks  Allow  Earlier 
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Composite  Tracks  Lead  To  Improved  Results 


Local 

Senso 


lo  impr 

■■■■■■■■III 

Earlier  First  Engagement 


Continuous  Composite  Tracks 


Fewer  Leakers 


Netted 


Local 


40%  50%  60%  70%  80%  90%  100% 


Average  %  of  Cruise  Missile  TOF 
Remaining  at  Time  of  1st  Intercept 


Local 


Netted 
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MDA 
'Jost  Teatn 


Software  Framework  for  Network-Centric  Interoperability 

II 


CEC/JCTN  Applique 

Dedicated  communication 
among  network  members. 


* 


Form  composite  tracks  using 
identical  data  and  identical 
software  on  all  platforms. 


Host  Legacy  Software 

sensor,  display,  BM/C3, 
weapon,  status,  training, 
data,  simulation,  comm  4 


Interface  to  BM/C3 
on  host  platform. 


JDN  Repairs  &  Enhancements 

•  registration,  correlation,  waveform 

•  time  slot  reallocation,  JICO  tools, 
joint  range  extension 

•  standard  TADIL  J  messages 
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Software  Functionality,  Modification,  Integration 

! 


•  Even  complex  defense  software  appears 
to  have  a  very  few  basic  patterns: 

•  Traditional  functions  (tracks,  navigation. . .) 
require  predictable  code  increments. 

•New  code  requires  predictable  amount  of 
modification  to  prior  existing  software. 

•  When  a  new  software  "build"  is  added  to 
existing  legacy,  the  required  integration 
effort  depends  largely  upon  the  size  of 
the  affected  legacy  (and  not  the  new  code). 


system  size 

IOoV  ksloc  =  f(interoperability  functionality) 
800  ksloc  =  26.7(modules) 

600  r2=091 
400 
200 


10  20  30 

number  of  modules 
(gridlock,  composite  track,...) 


Integration 

ksloc  integration  effort  =  f(legacy  sloe) 


modified  ksloc 
401 

30  y  =  0.27x 

20  R2  =  0.57 


modification  =  f(new  sloe) 


80  100 
new  ksloc 


UNCLASSIFIED  10 


127 


UNCLASSIFIED 

I  \C  ost  Team  a 


Component  Composition  of  Typical  Defense  Platform 


communication 

Link  4 
Link  11 
Link  16 
TCN 
CEC 
JCTN 

cm _ 


display 

tactical  plot 
CID,  status 


navigation 

chronometer-sextant-startracker 
inertial:  acceleration- velocity-displacement 
time-of-arrival  of  time-stamp  messages 


it 


sensor  registration  (position,  horizon,  north) 
relative  pairwise  &  global  absolute  gridlock 
synchronized  view  of  common  targets 
orientation  &  stability  on  platform 


lire  control 

platform  mgmt 

ROE 

salvo  tactic:  SS,  SLS 

C&D 

fire  control  solution 

precision  cue 

health  &  status 

+- 

P(K),  T(K) 

launch  on  remote 

test  &  diagnosis 

TEWA: 

engage  on  remote 

training 

shout- shoot 

forward  pass 

data  capture 

shout-listen-shoot 

BDA,  KA 

simulation _ 

- recursive  bidding 

sensors 

signal  process 

radar 

beam  form,  prf, 

SAR 

search  pattern 

IR 

< 

clutter 

IRST 

association 

EO 

track  form 

ESM 

track  update 

IFF/SIF 

doppler 

MTI  - 

It 


track  management 

local-remote  association 
reporting  responsibility  using  TQ 
data  pruning  using  TQ _ 

I 

CTO 

IFF/SIF 

trajectory 

micromeasures 
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Estimates  for  Functionality-SLOC-Cost  Translations 


platform  elements  ksloc 

platform  mgmt 

startup  &  test  25 

data  capture  25 

health  &  status  25 

diagnosis  75 

display  &  control  25 

dbms  &  access  75 

training 

operator  75 

analyst  75 

maintenance  75 

timing 

CPU  10 

emission-CPU  20 

navigation 

celestial  30 

inertial  30 

TOA  50 

sensor  registration 
relative  pairwise  30 

global  absolute  30 

PPLI  30 

common  target  30 


sensors 

radar 

beam-forming  100 

scan  patterns  100 

data  reduction  25 

clutter  suppression  50 

doppler  50 

SAR  accrual  100 

send  message  50 

receive  message  100 

IR  300 

IRST  600 

EO  300 

MTI  50 

ESM 

scan  patterns  50 

detect,  localize  50 

lookup,  classify  200 

sonar 

passive  300 

active  300 

tracker 

track  formation  25 

association  15 

track  update  15 

local-remote  association  15 
composite  tracks  30 

reporting  responsibility  15 
data  pruning  30 


cid 

IFF/SIF  100 

trajectories  1 00 

micromeasures  100 

communication 
link  4  25 

link  11  25 

link  16  100 

TCN  25 

CEC  50 

JCTN  50 

CDL  100 

crypto 

genser  25 

high  25 

multilevel  100 

battle  management 
interactive  display  200 

battle  plan  100 

threat  evaluation  200 

countermeasure  mgmt 
jamming  50 

decoys  50 

engagement  replay  50 


fire  control 

ROE  25 

fire  control  solution  50 

P(K),  T(K)  25 

integrated  fire  control 
precision  cue  25 

launch  on  remote  25 

engage  on  remote  25 

forward  pass  50 

salvo  techniques 

shout-shoot  10 

shout-listen-shoot  15 

recursive  bidding  25 

weapon  control 
launcher  mgmt  25 

firing  25 

telemetry  25 

simulation 

scenario  generation  50 

platform  simulation  50 

component  simulation  100 

s/w  assessment  25 

postprocessor  25 
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ADIL  J  Costs  Depend  Strongly  Upon  Integration  Choices 

I 


C  Services  report  widely  varying  unit  costs  to  implement  a  TADIL  J  message: 

•  USAF  &  USA  report  cost  per  message  of  ~  $  lm 

•  USMC  reports  cost  per  message  of  $  14m 

•  USN  reports  that  most  cost  is  for  host  integration 

Cost  Conjecture:  TADIL  J 


TADIL  J 

Message 

Costs 


Message  Design 
and  Coding 

•  2500  sloe  @$200 

•  $200  ODC/sloc 


Message  Design 
and  Coding 

r - 


Integration  with 
Legacy  Software 

_ A _ 


Integration  Effort  as 
%  of  Affected  Legacy 

•  3%  if  during  upgrade 

•  15%  all  other  times 

•  10%  observed  result 


Integration  Extent 

•  400  ksloc  comm 

•  400  ksloc  C&D 

•  400  ksloc  display 

•  400  ksloc  sensor 


Size  of  Host 
Legacy  SW 

•  OA  shrinks  50% 

•  CHS  shrinks 
FOS  totals 


Sample  Message  Costs  As  Driven  Largely  By  Integration  Circumstances: 

Low  $1m  =  (2500  sloc)($400)  +  no  integration  required  (or  wanted) 

Medium  $3.4m  =  (2500  sloc)($400)  +  (3%)(200  ksloc  OA  comm)($400) 

Very  High  $20.2m  =  (2500  sloc)($400)  +  (3%)(1600  ksloc)($400) 

Key  Questions:  Does  TADIL  J  message  arrival  automatically  update  host  data? 

Does  new  host  data  automatically  generate  TADIL  J  message? 
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Integration  Driven  by  Affected  Legacy  Software 

! 


Software  Active  and  Modifiable 
Software  Components  at  Various  Levels  of  Integration 


Display 

Feed 

Comp 

Full 

Size 

Name 

Function 

Only 

JCTN 

Tracks 

JCTN 

450k 

SPY 

radar 

X 

X 

X 

500k 

C&D 

command 

X 

X 

X 

450k 

ADS 

display 

X 

X 

X 

400k 

WCS 

weapon  control 

X 

350 

ORTS 

op  readiness 

X 

X 

X 

X 

350k 

ACTS 

training 

X 

X 

X 

X 

50k 

FCS 

fire  control 

X 

X 

X 

X 

900k 

ACSIS 

data/simulation 

X 

X 

X 

X 

Given:  Integration  Effort  m  0.10  x  Affected  Host  Legacy  Software 

Then:  Effort  for  JCTN  64k+OH  128k+OH  192k+OH  256k+OH 

Total  (including  OH)  -300k  -  350k  -  400k  -  450k 


Key  Point:  Host  integration  effort  steadily  increases  with  higher 
levels  of  interoperability,  with  a  minimum  effort  of  at 
least  0.5  of  the  maximum  integration  effort.  UNCLASS 


129 


UNCLASSIFIED 


Estimating  UML  Software  From  Modeling  Diagrams 

I 


UML  diagram  for  BMC3  design  for  coordinated 
space-search  &  air-search  for  time-sensitive  targets 


~o  o_. 

__o  p>,.o 

o  o. 


’1.0—  - 


A 


r  resulting  UML  sloe 


M 


J 


arrival = RANDOM(5,2, 5000) 
OUTFLOWS: 

dispersal =RAND0M(5, 1,3000) 


V 
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nteroperability  Efforts  Have  Required  Decades- 


1.  CEC  has  a  20-year  RDTE  span  with  12-year  installation  period 

•  PDRR  14  years  (1985-1998) 

•  EMD  10  years  (1995-2004) 

•  Produce  &  Install  12  years  (2000-2012) 


-Not  Years 

II 


JCTN  RDTE 


Sentinel  5 

Aegis  5 

E-2C  5 

TPS-59  6 

AWACS  8 

CEC/CRE  8 
Patriot  8 

MEADS  9 

JLENS  10 


A  CEC-like  JCTN  is  estimated  to  require  an 
8-year  (2005-2012)  RDTE  effort  for  design  and 
3  software  builds  to  achieve  1000  ksloc  new  code. 

3.  Integration  of  CEC/JCTN  by  FOS 
members  is  estimated  to  by  them 
to  average  8  years. 


2000  2005  2010  2015  2020 


4.  This  combination  of  CEC  +  JCTN  +  Integration  means  that  a  JCTN-based 
FOS  Interoperability  Architecture  is  possibly  achievable  by  2020  (not  2010). 


5.  However,  one  way  to  achieve  a  JCTN-based  architecture  close  to  2010  is  to  have 
FOS  members  start  preparing  today  to  join  CEC,  and  then  upgrade  to  JCTN. 
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ter  operability,  Integration,  &  Spiral  Development 

! 


Within-Block  Integration 

uses  Sensor  Netting  and 
BMC3  Netting  to  link 
Phases  within  a  Block. 


Within-Phase  Integration 
uses  Communication  to 
link  data  from  Sensor  to 
BMC3  to  Interceptor. 


Between-Block  Integration 
adds  Block  X+l  Increment 
to  Block  X  Legacy  (legacy 
will  drive  integration  costs) 


□=1 


BLOCK  X+l 


BLOCK  X 


■ . . . . . ""VOVSr PHASE 

SENSOR  l=|>  BMC3  l=^>  INTERCEPTOR 


j 


MIDCOURSE  PHASE  l 

SENSOR  1=^  BMC3  1=^  INTERCEPTOR 


A 


SENSOR  1=^  BMC3 

i  £>  within  phase  integration 
sensor  netting  integration 
multilayer  integration 


_ .  TERMINAL  PHASE 

1=^  INTERCEPTOR 


1-5%  of  each  integrand 
JCTN-like  comm  net 
JDN-like  comm  net 
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Information,  Attrition,  &  Architecture  Countermeasures 

I 


INFORMATION 

r - 

j  HIDE,  EVADE 
|  DISGUISE,  DECOY 


JAM, 
LISTEN 


FILTERS, 

AGILITY 


SEARCH, 

HOMING 


ATTRITION 


LETHALITY 


HARDENING 


:  \ 

ARCHITECTURE 

i - 

^ - j  PROLIFERATE,  j 

i  DISTRIBUTE,  J 
! CONCENTRATE  i 


v 

ACCURACY 


•  Countermeasure  arrays  sorted  by  primary  operational  mode — 
information,  architecture,  attrition — rather  than  location  or 
realm,  such  as  platform  or  network. 

•  For  every  measure,  there  appears  to  exist  at  least  one  counter¬ 
measure,  at  least  in  concept  if  not  yet  in  practice.  The  schematic 
displays  nondominance . 
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Network-Centric  &  Platform-Centric  Countermeasures 

I 


Interoperability  clarifies  shared 
data,  with  direct  impact  on  the 
“information”  sector  of  the 
countermeasure  schematics: 

•  enabling  search  &  homing 

•  penetrating  decoy,  evasion, 
&  disguise 

•  constituting  filters  &  agility 


Network-level  interaction  among 
sensors,  architecture,  &  stratagems. 


C2  Network  Countermeasures 


SPEED  <4- 


INTERCEPT, 
JAM 


DISTRIBUTE, 

CONCENTRATE 


BM  Countermeasures 

INFORMATION 


->  DECEPTION 


ATTRITION 


HIDE,  EVADE  _ FILTERS, 

DISGUISE,  DECOY  AGILITY 

- ►  !  LETHALITY - ►  HARDENING 

!  |  , 

ARCHITECTURE  [ 

f  | 

JAM,  \  SEARCH, 

|  PROLIFERATE,  |  ACCURACY 

ElOiDiN  —  HUMIJNCj 

L_  f 

i  DISTRIBUTE,  ' 

1  !  CONCENTRATE! 

Platform-level  interaction — but  possibly  force-level  impact 
-  among  maneuver,  sensors,  tactics,  force  size,  &  deployment. 
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UNCLASSIFIED 
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Estimate  to  integrate  THAAD  and  CEC/JCTN 

THAAD  Project  Office  565  ksloc 

MDA  Cost  Team  540  ksloc 

Estimate  to  test  CEC  on  AW  ACS 

AW  ACS  $45  M 

MDA  Cost  Team  $50  M 

Reconciliation  of  JCTN  estimates  of  integration 
costs  with  both  THAAD  and  Patriot  within  $1M 
after  assumptions  made  comparable  (same  software 
maintenance  levels,  etc) 


UNCLASSIFIED  20 


132 


etwork-Centric  Interoperability  Lessons  Learned 

! 


•  Keep  a  very  strong  focus  on  the  BASIS  of  costing 

•  Cost  estimation  and  technical  design  can  greatly  help  each  other 

•  Understanding  &  estimating  cost  drivers  is  difficult  but  essential 

•  Good  approximation  »  detailed  error 

•  Avoid  detailed  cost  accounting  schemes 

•  Focus  on  approximating  the  main  drivers 

•  Excursions ,  sanity  checks ,  sensitivity 

•  Uncertainty  makes  a  family  of  estimates  essential 

•  “Approximate  Cost  Previews” 

•  Examine  neighborhoods  and  boundaries 

•  Full  life-cycle  estimates  to  find  trades ,  avoid  surprise 

•  Example:  reliability  trades  RDTE  vs  Production  vs  O&S 

•  Example:  Stopping  at  FUE  can  hide  Production  and  O&S  growth 

•  Failure  analysis  (beyond  risk ,  sanity ,  sensitivity) 

•  What  might  failures  look  like? 

•  Search  for  cost  precipices  &  precursors  of  failure 
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Interoperability  Cost  Estimation  Backup 

•  Software  As  A  Basis  Of  Estimation 

•  How  CEC  Can  Evolve  To  JCTN 

•  AEGIS  Integration  Details 

•  Open  Architecture  &  Common  Host 

•  Interoperability  Cost-Benefit  With  Link  16  &  CEC 
and  Common  Host  &  Legacy  Software 

•  Interoperability  Cost  Estimation  Experience 

•  Estimated  Costs  of  Field  Testing  Interoperability 
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Macro  &  Micro  Software  Enabling  Patterns 


Primary  Macro  Software  Pattern 


•  Each  platform  is  a  software  ensemble. 

•  Legacy  platform  software  can  be  replaced  by  Open 
Architecture,  Common  Host,  or  an  OA-CH  sequence. 

•  Replacing  legacy  software  with  Open  Architecture 
can  produce  new  platform  software  on  each  platform 
whose  size  is  about  0.5  of  the  legacy  sloe  it  replaces. 

•  Replacing  legacy  software  with  Common  Host  can 
produce  a  single  new  platform  software  for  all  platforms 
whose  size  is  about  0.5  of  a  single  platform’s  legacy  sloe. 

•  Current  strategies  to  improve  platform  interoperability 
include  improving  improving  communications,  augmenting 
battle  manager,  and  overhauling  entire  legacy  software. 

•  Improving  communication  means  Link  16  Repairs  & 
Enhancements  (TSR,  JRE,  JICO,  Standard  Messages). 

•  Battle  Manager  augmentation  often  means  a  CEC/JCTN 
common  kernel  processing  shared  sensor  data  from  a 
wideband  sensor  communications  net. 

•  Common  Host  &  Open  Architecture  lower  Integration 
cost  of  JDN  &  CEC/JCTN  by  reducing  platform  sloe  size. 


Primary  Micro  Software  Patterns 


system  size  (ksioc)  ks|oc  =  f(jnteroperability  functionality) 
1000 


0  10  20  30 

number  of  modules 
(gridlock,  composite  track,...) 


Platform  functions  &  capabilities  usually  require 
predictable  amounts  of  software  &  integration. 

Modification  of  existing  software  by  new  code  is 
on  average  4  lines  new  =>  1  line  modified. 

Integration  effort  is  driven  by  the  size  of  affected 
legacy,  generally  equivalent  to  10%  of  legacy. 
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Platform  Functionality  In  A  Network  Context 


•  Each  platform  contains  an  ensemble  of  legacy  software 
that  operates  its  primary  activities:  sensor,  display, 
BMC3,  weapon,  status,  navigation,  communication. 

•  Two  basic  strategies  exist  to  improve  interoperability 
among  platforms:  either  improve  specific  platform 
modules  like  BMC3  or  communications,  or  overhaul 
legacy  software  using  Open  Architecture,  Common  Host, 
or  do  both. 

•  Open  Architecture  and  Common  Host  both  provide  very 
compact  software,  with  reduced  maintenance  and  reduced 
integration  for  module  improvement. 


□ 


•  Each  platform  element  contains 
multiple  elements,  which  may  be 
ensembles  like  Link  4,  Link  1 1 , 
Link  16... or  alternatives  like 
chronometer,  INS,  TO  A  navigation. 

•  Platform  elements  include 
provision  for  successive 
enhancement: 

shout-shoot,  shout-listen-shoot,  bid 
precision  cue,  launch  on  remote,  EOR 


communication 

Link  4 
Link  11 
Link  16 
TCN 
CEC 
JCTN 

CDL _ 


Lt  -startracker 
i  -velocity  -displacemi 
ne  -stamp  messages 


Vf 


display 

tactical  plot 
CID,  status 


sensor  registration  (position, 
relative  pairwise  &  global  absolu 
synchronized  view  of  common  tarj 


sensors 

radar 

SAR 


doppler 


Vf 


track  management 


fire  control 

4 

reporting  responsibility 
data  pruning  using  TQ 

platform  mgmt 

C&D 

ROE 

fire  control  solution 
P(K),T(K) 

TEWA: 

shout  -shoot 

salvo  tactic:  SS,  SLS 
precision  cue 

t  BDA,  KA 

A 

test  &  diagnosis 

data  capture 

4 

CID 

IFF/SFF 

trajectory 
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From  Functional  Schematic  to  SLOC  Estimate 


•  Software  required  to  implement  functionality 
based  on  experience  of  existing  platforms 
and  on  engineering  designs  of  new  systems. 

•  Platform  management,  display,  sensors, 
communication,  &  signal  processor  software 
data  from  diverse  platform  experience. 

•  Designs  for  successive  improvement  include 
software  estimates: 

shout-shoot,  shout-listen-shoot,  recursive  bid 
precision  cue,  launch  on  remote,  EOR 


communication 


CDL 


display 

CID,  status 


platform  mgmt 

C&D 


sensors 

signal  process 

radar 

beam  form,  prf. 

SAR 

search  pattern 

IRST 

association 

EO 

track  form 

ESM 

IFF/SFF 

doppfe 

track  management 


data  pruning  using  TQ 


CID 

IFF/SFF 


•  All  major  functions  are  broken  out  into 
detailed  components  or  alternatives. 
Different  communication  links,  different 
sensors,  different  signal  processing 
techniques,  sensor  registration  are  all  called 
out  separately  &  explicitly. 

•  Some  listed  techniques  are  placeholders — 
JCTN,  forward  pass,  recursive  bidding — 
included  to  allow  comparison  with  existing 
approaches. 
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T  Shoutback  Aegis  Integration  Basis  of  Estimate  (NTW  04  Capability  Configuration 


1  |  Stand  Alone 

[  |  Integrated 


-  Digital  Interface 

- Video  Interface 


*  SLOC  annotations  from  MDA  Cost  Team 
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AEGIS  Shoutback  Intel 


aegis  ksloc  estimates  ksloc 


ration  Potential  Cascades 

II 


Shoutback  Entry 
at  MTRS  Into 
Aegis  Platform 
Ensemble  of 
Software. _ 


C&D 

ACDS 

SPY 

WCS 

ORTS 

ACTS 

FCS 

ACSIS? 

aegis  system  subtotal 

LAMPS 
AN/SPS-55 
ID  SYSTEMS 
JTT 

ELEC  SENS  SYS 
NAV  SYS 
MTRS 
C2P 

EW  SYSTEM 
VLS 

PHALANX 

SSDS 

integrated  subtotal 


500 

450 

450 

400 

350 

350 

50 

900 

3450 

300 

300 

100 

100 

300 

100 

100 

200 

100 

50 

50 

100 

1800 


Integration  of  Shoutback  data 
(and  the  J  10.2  message)  into 
primary  the  Aegis  ensemble, 
integrated  elements  (e.g.  SSDS), 
but  probably  not  into  stand-alone 
elements  (such  as  sonar). _ 


/ 


SONAR  600 

GCCS  100 

GUN  FIRE  CONTR  50 

TOMAHAWK  50 

HARPOON  50 

UW  FCS  100 

stand-alone  subtotal  950 
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pvork-Centric  Open  Architecture  &  Common  Host  Options 

I 


Host  Legacy  Software 

BM/C3,  display,  sensor, weapon,  data, 
status,  training,  comm,  simulation 

100-400  ksloc  per  host  module 
1000-5000  total  ksloc  per  host 
*  16,000  ksloc  total  for  FOS 


4 

Establish  crosswalks  among  legacy 

modules  and  identify  specifications  that 
satisfy  all  FOS  members  for  status,  display,  ... 

Reverse  engineering  @  S100  per  line  for  a 
typical  large  FOS  with  16  msloc  overall 

«  $1.6b  for  system  design 


Create  Open  Architecture  to  replace 
legacy  software  for  each  FOS  member: 

•  OA  sloe  =  0.5  legacy  sloe 

•  For  a  typical  large  FOS,  16  msloc  =>  8  msloc 
at  a  cost  of  $3.2b  for  Open  Architecture 

1 

Establish  crosswalks  among  open  architecture 
modules  and  identify  specifications  that  satisfy 
all  FOS  members  for  status,  display,  .... 

Reverse  engineering  @  $100  per  line  for 
a  typical  large  FOS  with  8  msloc  overall 

«  $0.8b  for  system  design 


i 


Common  host  software  coding  of 
2  msloc  @  $200  **  $400m  for  code 
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Estimated  SIAP  Cost-Performance  Trades  w.  Host  Legacy 

! 


Joint  SIAP  for  CEC-based 
JCTN  on  all  platforms 


Enhanced  Link  16  + 
JCTN  on  all  platforms 


Joint  SIAP  for  CEC  w  AWACS 


Enhanced  Link  16 
+  CEC  w  AWACS 


I  USN  SIAP  for  CEC  on  USN 

♦  Joint  SIAP  for  CEC  on  USN 

Existing  Link  16  *  Enhanced  Link  16 

: - 1 - 1 - 1 - 1 

2000  4000  6000  8000 

Cost  in  FY00  $M 


Enhanced  Link  16  +  CEC 


Notes  and  Assumptions: 


1.  CEC  includes  Aegis,  CV,  LH,  E-2C,  TPS-59,  and  worst-case  $1.2  billion  for  CEC-JDN  integration. 

2.  Other  platforms  treated  are  Patriot,  MEADS,  AWACS,  TPS-75,  surveillance  a/c. 

3.  Enhanced  JDN  includes  JDN  repair  (sensor  &  navigation  registration,  common  correlation,  pack-4 
waveform),  JDN  enhancements  (TSR,  JRE,  JICO),  and  30  standardized  TADIL  J  messages. 

4.  SIAP  coverage  is  as  estimated  by  IDA  for  JMAA  theater  scenarios;  costs  are  from  JTAMD  Cost  Panel. 

5.  Not  considered  are  legacy  software  initiatives  like  Open  Architecture  or  Common  Host  Software. 

6.  Not  included  are  sunk  costs  estimated  to  be  $7  billion  for  JDN  and  $2  billion  for  CEC. 
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stint ated  SIAP  Cost-Performance  Trades  w  Common  Host 

I 


%  SIAP 
Coverage 

100 


Joint  SIAP  for^ 
CEC  w  AWACS* 


50 


Joint  SIAP  for  CEC-based 
JCTN  on  all  platform: 


"i 


Enhanced  Link  16  + 

4^  JCTN  on  all  platforms 

Enhanced  Link  16  +  CEC  w  AWACS 


USN  SIAP  for^ 

CEC  on  USNT 
Joint  SIAP  fort 
CEC  on  USN  ▼ 

Existing  Link  16  +  Enhanced  Link  16 


Enhanced  Link  16  +  CEC 


2000  4000  6000  8000 

Cost  in  FY00  $M 


Notes  and  Assumptions: 

1.  CEC  includes  Aegis,  CV,  LH,  E-2C,  TPS-59,  and  worst-case  $1.2  billion  for  CEC-JDN 
integration  (less  net  integration  savings  for  using  common  host  software.) 

2.  Other  platforms  treated  are  Patriot,  MEADS,  AWACS,  TPS-75,  surveillance  a/c 

3.  Enhanced  JDN  includes  JDN  repair  (sensor  &  navigation  registration,  common  correlation,  pack-4 
waveform),  JDN  enhancements  (TSR,  JRE,  JICO),  and  30  standardized  TADIL  J  messages. 

4.  SIAP  coverage  is  as  estimated  by  IDA  for  JMAA  theater  scenarios;  costs  are  from  JTAMD  Cost  Panel. 

5.  Not  included  are  sunk  costs  estimated  to  be  $7  billion  for  JDN  and  $2  billion  for  CEC. 
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ipact  of  Common  Host  on  SIAP  Cost-Performance  Trades 

I 


%  SIAP 
Coverage 
100 


Enhanced  Link  16  + 


50 


0* 


Joint  SIAP  for  CEC-based 
JCTN  on  all  platforms  „  ,  ,r 

+  ..J.C.IN..o.n..all..p.latfQrms . 

Joint  SIAP  for4 . O  + . — . O 

CEC  w  AWACS  Enhanced  Link  16  +  CEC  w  AWACS 


USN  SIAP  for 
CEC  on  USN 

Joint  SIAP  for  A 
CEC  on  USN  “ 
^Existing  Link 


♦ . o  V 


Enhanced  Link  16  +  CEC 


❖ 


o 

^  Enhanced  Link  16 


16 


0  2000  4000  6000  8000 

Cost  in  FY  00  $M 

Notes  and  Assumptions: 

1.  CEC  includes  Aegis,  CV,  LH,  E-2C,  TPS-59,  plus  $1.2  b  for  CEC-JDN  repairs  less  net  CHS  savings. 

2.  Other  platforms  treated  are  Patriot,  MEADS,  TPS-75,  surveillance  a/c 

3.  Enhanced  JDN  includes  JDN  repair  (sensor  &  navigation  registration,  common  correlation,  pack-4 
waveform),  JDN  enhancements  (TSR,  JRE,  JICO),  and  30  standardized  TADIL  J  messages. 

4.  SIAP  coverage  is  as  estimated  by  IDA  for  JMAA  theater  scenarios;  costs  are  from  JTAMD  Cost  Panel. 

5.  Not  included  are  sunk  costs  estimated  to  be  $7  billion  for  JDN  and  $2  billion  for  CEC. 
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Establishing  the  Basis  of  Cost  Estimate 

I 


Establishing  Cost  Basis 

Software  System  Engineering 
for  CEC,  JCTN,  Standardized 
JDN,  Open  Architecture,  and 
Common  Host  Software 

Theater  Missile  Defense 
Schedule/Technical  Risk  for 
NTW,  MEADS,  ABL,  SBL, 
NADS,  and  SBIRS. 

National  Missile  Defense 
Schedule/Technical  Risk  for 
BMC3,  GBI,  SEI,  and  D&S 


CEC 

JCTN 

Gateway 

Standardized  JDN 
Open  Architecture 
Common  Host  Software 


SIAP  IFC  &  PIM 


Defense  Platforms  Studied 

^AEGIS,  CV,  LH,  E  2C,  TPS-59, 
SBIRS,  THAAD,  Patriot,  JLENS, 
MEADS,  Sentinel,  Rivet  Joint, 
NADS,  NTW,  TPS  75,  AWACS, 
JSTARS,  Predator,  Global  Hawk, 
ABL,  F-22,  JSF,  F/A-18  E/F, 
Vj/A-16  Block  50,  DD(X) _ 


x 


Project  Estimates 


JDEP 

National  Cruise  Missile  Defense 

Demonstration  Unit  Costs 

BMD  SAS  Interoperability 

Link  16  for  TBMD 

JMAA 

Hercules 

RAMOS 

SIAP  Alternatives 
SBIRS-Aegis  Alternatives 
TBMD  Integrated  Fire  Control 
NATO  TAMD  Interoperability 
BMPS  Integration  &  BMC3 
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efense  Platform  Cost  Estimates  Without  CARD  1996-2003 

I 


CEC 

Created  20-year  RDTE  detailed  technical  profile  to  relate  specific  functions  to  software  size. 

JCTN 

Created  10-year  RDTE  detailed  technical  profile  as  a  direct  extension  of  CEC,  relating  expanded 
functionality  to  successive  software  builds  and  sloe  growth. 

JTAMD  Master  Plan 

Estimated  costs  of  a  baseline  JTAMD  architecture  defined  by  the  O&A  WIPT,  treated  as  a  JCTN 
baseline  excursion. 

Minimum  Mix 

Revisited  CEC/JCTN  concepts  including  participation,  integration  levels,  population  sizing  for  a  top- 
down,  bottom-up  JCTN  cost  scrub. 

Gateway 

Identified  software  functionalities  required  to  implement  JCTN/JDN  Gateway. 

JTAMD  Demonstrations 

Used  MDAP  CEC/JCTN  integration  approaches  and  estimates  to  develop  estimated  unit  costs  of 
missile  defense  field  tests  and  demonstrations. 

IPP Increments  4-7 

Identified  the  selected  subset  of  JCTN functionality  that  corresponded  to  the  IPP  framework. 

Identified  $5B  overlooked  costs  due  to  FUE  limited  horizon. 

National  CMD 

Created  architecture  &  conops  of  layered  multiple  corridors  defended  by  Aegis,  Patriot, 

A  WACS+CAP. . .  Estimated  patrol  O&S  cost  =  $5M/week/layer/corridor 

Common  Host  Initiative 

Devised  software  strategies  to  derive  Open  Architecture  and  Common  Host  coordinated  software 
replacements  for  family  of  system  legacy  ensembles. 

BMDSAS  Capital  Budget 

Estimated  the  interoperability  integration  costs  of  a  long-term  capital-budgeting  approach  to 
upgrading  defense  platform  ensembles 

JMAA 

Defined  solution  techniques  for  JDN  repairs,  enhancements,  and  standardized  TADIL  J  messages, 
then  estimated  the  costs  to  implement  and  integrate  the  implemented  solutions  into  FOS platforms. 

RAMOS 

Defined  Engineering  Integration  Team  roles,  missions,  &  structure,  and  likely  Soviet  cost  drivers, 
estimated  major  RAMOS  architectural  and  O&S  alternatives. 

SIAP  Block  1,  PIM/PSM 

Developed  a  general  platform  model  that  describes  how  desired  platform  functionality  and 
interoperability  drives  software  size. 

NATO  Feasibility 

Reviewed  draft  TAMD  Architecture  Feasibility  Studies  and  identified  missing  essential  elements  that 
create  or  prevent  system  feasibility.  The  revised  studies  may  have  some  value. 

BMDS  Block  06,  KE  Boost 

Developed  a  general  platform  model  that  describes  how  desired  platform  functionality  and 
interoperability  drives  software  size.  UNCLASSIFIED  3 
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Estimated  Costs  of  Testing  Interoperability 

1 1 II 


estin^^ntei^M 


PerformanceVenueExpected  Roleof  Est im  ateEstim  ated  Number  of  Trials, Uni 


Why  the  proliferation  of  performance  trials: 

(2  sensors)(2  networks)(2  weapons)(4  target  types)  =  32  combinations 
+  variations  in  force  size  and  geography 
+  variations  in  firing  doctrine,  etc 
+  variations  in  threat  size  and  capability 
+  repetition  to  gain  confidence  in  results 

Some  ways  to  mitigate  performance  estimation  cost: 

•  augment  existing  exercises  vs  JT AMD-dedicated  trials 

•  substitute  JDEP  and  simulation  for  field  trials 

•  coordinated  program  of  field  test,  JDEP,  and  simulation 
- *  spiral  development  to  winnow  choices  &  also  choose  more  wisely 
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Introduction 


The  concept  of  interoperability  has  a  broader  scope  than  merely  data  exchanges.  It  may  describe 
the  ability  to  request  and  receive  services  between  various  systems  and  use  their  functionality.  In 
this  more  general  sense  interoperability  implies  the  existence  of  features  such  as:  exchange  of 
messages  and  requests,  mutual  use  of  system  components’  functionality,  at  least  client-server 
abilities,  distribution,  operate  multiple  systems  as  a  single  unit,  communication  despite 
incompatibilities,  extensibility  and  evolution. 

The  Multilateral  Interoperability  Programme  (MIP)  is  one  major  international  effort  to  attain 
interoperability  among  NATO  information  systems.  MIP  gets  a  lot  of  visibility  because  its 
interoperability  standard  is  actually  incorporated  in  operational  systems  and  tested  “in  the  field”. 
The  MIP  interoperability  approach  provides  a  promising  solution,  especially  with  respect  with  its 
exchange  data  model,  C2IEDM  (C2  Information  Exchange  Data  Model). 

C2IEDM  represents  a  reference,  or  a  central  data  model  as  the  of  an  interoperability  solution.  By 
providing  a  single  data  model,  this  is  in  fact  an  ideal  technical  solution.  It  has  also  the 
indisputable  advantage  of  being  a  widely  accepted  solution.  Nevertheless,  it  still  requires 
considerable  implementation  and  maintenance  effort.  It  can  be  argued  that  system-wide 
interoperability  can  be  improved  considerably  by  harmonizing  instead  of  centralizing  around  a 
single  data  model,  all  major  information  modeling  efforts  within  DoD,  including  C2IEDM. 

Interoperability  contexts  can  be  defined  for  different  interoperability  solutions.  Interoperability 
domains  can  be  defined  by  identifying  the  information  services  relevant  to  a  given  context.  To  do 
this,  it  is  necessary  to  define  what  an  interoperability  solution  is,  and  classify  all  these  solutions. 
One  can  then  associate  interoperability  domains  with  interoperability  solutions.  This  approach  is 
more  flexible  than  imposing  a  unique  reference  data  model  for  all  interoperability  contexts. 

Interoperability  cannot  be  efficiently  addressed  as  a  whole,  and  as  a  consequence  the 
interoperability  solutions  are  not  unique.  There  is  currently  a  common  and  significant  trend 
towards  interoperability  approaches  that  recognize  this  important  aspect.  Interoperability  models 
are  proposed  using  quite  similar  concepts  such  as  interoperability  layers,  degrees  of 
interoperability,  or  interoperability  levels. 
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We  argue  there  is  no  universal,  system-wide  interoperability  solution;  any  solution  covers  only  a 
given  portion  of  the  full  interoperability  problem  space.  Although  theoretical  completeness  can 
still  be  a  strong  criterion  of  adoption,  the  validity  of  any  solutions  is  always  expressed  by  the 
degree  it  satisfies  practical  requirements  of  specific  and  real  situations. 

We  will  briefly  describe  some  relevant  interoperability  models,  and  we  propose  a  context-based 
model  for  NCES,  arguing  that  even  if  the  current  approaches  are  necessary,  they  are  not 
sufficient  in  the  long  run. 

From  a  theoretical  point  of  view,  there  are  at  least  three  different  levels  of  abstraction  for  data 
modeling:  syntax,  semantics  and  pragmatics  or  operations.  At  each  level  data  models  can  be 
constructed  and  expressed  by  using  specific  languages  and  tools. 

We  argue  that  for  an  interoperability  model  to  succeed  two  conditions  are  necessary:  it  has  to 
address  each  interoperability  problem  in  its  own  interoperability  context,  and  all  levels  of  data 
abstractions  have  to  be  explicitly  addressed  by  the  model. 

What  is  Information  Interoperability? 

In  essence,  information  interoperability  refers  to  the  unambiguous  information  exchange 
between  sources  that  are  willing  to  share  their  information.  In  other  words,  data  that  crosses 
different  systems  has  to  be  correctly  interpreted.  In  practice,  there  are  certain  obstacles  that 
usually  prevent  the  realization  of  a  simple  interoperability  solution.  The  analysis  of  the  usage 
scenarios  helps  to  understand  the  nature  of  these  obstacles  in  a  given  situation. 

One  of  the  most  common  problems  that  have  to  be  overcome  by  interoperability  is  the 
information  infrastructure  heterogeneity.  In  a  heterogeneous  system  environment,  it  is  often 
possible  that  data  be  represented  using  various  formalisms  and  methods  such  as  relational 
databases,  XML  documents,  proprietary  databases,  object  oriented  databases,  file  records,  etc. 
Some  interoperability  solutions  can  be  provided  by  different  middleware  approaches. 

It  is  also  not  unusual  that  some  repositories  have  almost  the  same  content,  using  the  same 
formalism,  but  being  differently  structured.  The  interoperability  approach  may  provide  solutions 
to  this  problem  by  matching  semantically  compatible  elements  and  by  mediating  between 
different  representations,  in  general,  mapping  across  representation  systems.  Mediate  between 
different  representations  essentially  means  to  reconcile  different  representations  of  the  same 
concept. 

Most  data  models  were  invented  for  operations  that  didn’t  involve  data  interoperability,  such  as 
accessing  and  retrieving  from  known  data  sources.  Interoperability  issues  appear  when  data 
sources  are  not  necessarily  known,  and  when  the  format  and  content  of  data  are  different  or  even 
unknown  at  the  design  time.  We  need  a  data  model  that  specifically  addresses  the 
interoperability  between  different  data  models  at  more  abstract  levels.  Without  it  any  attempts  to 
solve  interoperability  problems  risk  to  be  inconsistent,  partial,  and  difficult  to  generalize  for  new 
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data  models.  We  need  a  model  that  can  be  applied  to  all  data  operations  that  take  place  in  the 
systems:  searching,  retrieving,  accessing,  interpreting,  aggregating,  fusing,  mapping,  etc. 


Engineering  Information  Interoperability 

The  information  interoperability  architectures  are  inherently  biased  towards  the  architectural 
concepts  used  for  the  systems  they  are  part  of.  Traditionally,  the  interoperability  design  made  use 
or  adapted  concepts  from  the  relational  databases  and  client  server  architectures  for  distributed 
systems.  Recently,  the  main  architectural  themes  are  the  Enterprise  Application  Integration 
(EAI),  Service  Oriented  Architectures  (SOA),  Web  Services,  and  in  perspective  the  Semantic 
Web.  Concepts  and  patterns  from  these  different  architectures  are  to  be  found  in  today’s 
interoperability  design. 

Important  to  note  is  that  choosing  the  right  interoperability  architecture  is  not  always  only  a 
technology  option.  Different  architectures  can  actually  coexist  or  can  be  used  in  layered 
approaches,  mainly  due  to  practical  engineering  reasons  such  as  effectiveness,  robustness,  or 
cost,  rather  than  architectural  “purity”. 

Some  solutions,  such  as  for  instance  data  standardization  might  work  well  for  small,  simple 
enterprises.  For  larger  enterprises,  it  seems  more  appropriate  to  have  many  data  models,  each 
covering  a  given  functional  domain,  so  that  the  systems  can  adopt  data  definitions  from  the 
appropriate  model.  As  a  result,  the  interoperability  focus  moves  towards  the  communication 
between  systems,  across  the  boundaries  of  different  models. 

Some  interoperability  solutions  will  be  enumerated  in  the  following.  This  does  not  represent  a 
systematic  approach;  it  is  rather  an  attempt  to  place  the  current  efforts  into  a  more  general 
perspective. 

Unique  data  model  or  data  standardization.  A  new,  unique  data  model  is  defined  for  different 
information  systems  with  different  data  models.  This  is  one  of  the  simplest  ways  of  achieving 
information  interoperability.  It  has  its  advantages,  such  as  being  very  easy  to  use  by  the  end 
users,  as  it  appears  to  be  one  single  information  system.  In  turn,  it  is  difficult  to  define,  because  it 
needs  human  understanding  to  define  an  integrated  data  model.  Another  disadvantage  is  the  loss 
of  local  autonomy,  with  all  its  consequences  -  difficult  to  maintain,  cannot  adapt  easily  to 
specific  local  requirements,  etc.  It  is  also  a  static  solution  in  the  sense  that  it  cannot  evolve 
automatically  -  there  is  always  a  need  for  human  intervention  to  define  new  data  model 
elements. 

Database  replication  mechanisms.  Replication  is  the  process  of  copying  and  maintaining 
database  objects  in  multiple  databases.  Basic  replication  is  useful  for  information  distribution. 
Using  replication  critical  information  is  always  available,  relatively  current,  and  consistent  at  all 
targets.  Although  it  can  be  generalized,  this  approach  is  in  its  present  form  limited  to  relational 
database  environments,  where  it  has  been  first  defined  and  used.  An  example  of  this  approach  is 
offered  by  the  MIP  replication  mechanism  -  ARM. 
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Federated  Databases.  This  refers  to  a  set  of  individual  databases  which  are  managed  coherently. 
Each  database  contains  a  logically  connected  group  of  objects.  Objects  can  hold  references  to 
each  other,  allowing  navigation,  including  from  one  database  to  another. 
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Semantic  hub  -  a  central  dynamic  semantic  model 

Table  1  Interoperability  Strategies 

A  central  administration  provides  the  reconciliation  between  differences.  The  source  systems 
provide  the  physical  data  and  a  middleware  layer  translates  the  requests.  This  approach  requires 
that  that  each  database  system  can  execute  these  requests. 

Static  Data  Transformations .  This  approach  assumes  the  existence  of  pre-defined  data 
translations  between  each  pair  of  communicating  systems,  without  any  specification  of  their 
underlying  data  model.  This  represents  a  procedural  approach  in  the  sense  that  it  defines  how  to 
process  data  instead  of  describing  the  data  itself.  It  is  also  static,  because  it  is  defined  at  the 
design  time  and  cannot  be  changed  dynamically  at  the  execution  time.  The  semantics  of  each 
data  model  has  to  be  fully  understood  only  by  the  developers,  and  the  translations  support  only 
the  information  transfer  anticipated  during  the  development.  This  architecture  cannot  provide 
any  system  functionality  that  can  ensure  the  dynamic  generation  of  translations  at  run-time.  The 
development  and  maintenance  of  such  translations  require  considerable  effort,  particularly  with 
the  increase  of  the  number  of  communicating  systems. 

Nevertheless,  this  approach  continues  to  be  very  popular,  due  mainly  to  the  popularity  of  textual 
languages  such  as  extensible  Stylesheet  Language  Transformation  (XSLT).  The  same  principles 
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can  be  applied  to  other  data  structures,  such  as  EDI  messages,  or  to  disparate  database  tables 
using  SQL,  although  the  popularity  of  the  method  is  due  by  far  to  the  growing  number  of  XML 
structures  in  place  today. 

Dynamic  Data  Transformations.  This  more  flexible  procedural  scheme  assumes  that  the 
translations  are  automatically  generated,  at  run  time,  from  descriptions  of  the  data  used  by  the 
communicating  pair.  These  descriptions  need  to  be  expressed  in  a  formal  language,  in  the  sense 
that  this  language  has  to  be  machine  understandable,  at  run  time.  It  is  also  necessary  that  the 
descriptions  to  be  based  on  a  common  understanding  of  the  meaning  of  the  data  elements.  This 
common  meaning  has  also  to  be  expressed  in  a  machine  understandable  manner,  so  that  the 
mediator  can  identify  and  correlate  related  elements  from  different  data  models. 

Data  Mediation.  This  approach  uses  a  mediator  metaphor  for  interoperability.  The  data  mediator 
essentially  translates  data  between  two  systems  with  different  data  models.  The  mediator 
dynamically  generates  data  translations  according  to  deployed  transformation  logic. 

There  is  no  assumption  on  the  static  or  dynamic  nature  of  the  data  translation  itself.  Lor  instance, 
the  translations  can  be  achieved  by  using  static  data  transformations  stored  in  special 
repositories,  such  as  metadata  repositories.  This  approach  may  still  have  all  the  drawbacks  of 
static  data  transformations,  but  offers  the  advantage  of  reducing  the  number  of  peer-to-peer 
connections. 

Central  Information  Model.  The  information  model  is  central  in  the  sense  it  represents  a  neutral 
and  unifying  view  of  a  group  of  data  models.  Neutral  means  that  it  doesn’t  serve  any  particular 
domain  needs,  and  it  is  unifying  in  the  sense  that  it  serves  some  common  purposes  of  the  group. 
Each  of  the  resources  can  be  mapped  to  the  central  model. 

The  basic  architectural  concepts  of  this  approach  are  similar  with  those  of  the  hub-and-spoke 
architecture  for  asynchronous  message  busses.  The  idea  of  a  hub-and-spoke  is  that  instead  of 
sending  messages  between  each  pair  of  sending  and  receiving  applications,  the  source  can  send  a 
message  on  the  bus,  while  the  potential  target  applications  listen  for  their  messages.  Lor 
information  interoperability,  the  hub  can  be  represented  by  an  agreed  upon  central  or  reference 
data  format,  with  the  spokes  represented  by  any  number  of  other  formats.  XML  is  currently  the 
most  largely  known  example  of  a  format  for  a  data  hub.  Interoperability  technologies  can  import 
data  from  most  common  formats  and  convert  it  to  the  hub  format.  The  hub  metaphor  is  used  by 
many  system  designers.  One  of  the  examples  is  the  MIP  C2IEDM  which  is  also  known  as  the 
General  Hub  (GH). 

Semantic  Information  Model. 

This  model  addresses  the  most  challenging  incompatibility  problems,  those  that  arise  from 
semantic  differences  in  the  structure  or  schemas  of  data.  While  a  common  data  format  may  never 
be  achieved,  this  approach  has  the  goal  to  establish  a  common  understanding.  Semantics  may 
save  time  by  ideally  capturing  the  meaning  of  data  once.  Another  important  benefit  of  using 
semantic  descriptions  is  that  large  numbers  of  data  sources  can  turn  into  one  coherent  body  of 
information.  This  can  then  provide  a  common  understanding,  keeps  data  consistent  and  well 
defined.  While  informal  data  semantics  has  always  existed,  a  more  formal  semantics  brings  in 
the  advantage  of  being  equally  “understood”  by  machines. 
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This  information  model  may  be  based  on  any  traditional  data  model  or  object  model  but  it  could 
also  be  centered  on  ontologies,  a  modeling  technique  developed  for  expressing  semantic 
relationships  between  the  elements  of  a  data  model.  An  ontological  information  model  is 
potentially  richer  than  a  traditional  data  model,  including  more  levels  of  generalization,  business 
rules,  etc.  Its  generality  allows  the  information  model  to  serve  as  an  authoritative  reference  for 
multiple  data  sources,  regardless  of  format  or  technology. 

In  conclusion,  one  might  state  that  any  of  the  interoperability  techniques  offers  only  a  partial 
solution.  The  whole  solution  could  be  for  instance,  data  standardization  up  to  the  point  when  it 
doesn’t  become  impossible  to  manage,  complemented  with  data  mediation  for  individual  systems 
that  need  to  maintain  their  data  independence  but  need  to  cooperate.  Any  of  the  partial  solutions 
helps  in  certain  ways,  and  it  is  the  architect’s  and  designer’s  job  to  determine  the  right  mix. 


NATO  C3  Series  of  Interoperability  Models 

The  NATO  C3  Technical  Architecture  [NATOTechArch]  uses  a  series  of  interoperability 
models,  covering  interoperability  problems  ranging  from  unstructured  data  exchange  to  seamless 
sharing  of  information.  The  interoperability  models  are  part  of  the  NATO  C3  System 
Architecture  Framework  (NAF)  which  is  mandatory  for  the  NATO  systems  and  recommended  to 
be  used  by  nations  for  the  purpose  of  achieving  interoperability. 

NATO  uses  two  types  of  data  models:  the  NATO  Corporate  Data  Model,  and  the  NATO 
Directory  Data  Model.  The  basic  principle  for  achieving  interoperability  is  to  separate  data  from 
applications  and  applications  from  the  computing  platforms. 

The  NATO  Corporate  Data  Model  has  been  developed  by  The  NATO  Data  Administration 
Group  (NDAG),  a  multi-national  working  group.  The  goal  of  this  model  is  to  provide  a  source 
for  Standard  Data  Elements  (SDE).  The  use  of  SDEs  enhances  interoperability  among  NATO  C3 
systems.  A  Reference  Model  contains  the  semantic  descriptions  of  the  SDEs,  their 
interrelationships  and  information  about  data  structures  (ex:  maximum  field  length,  data  types, 
etc.).  Several  project-centric  View  Models  represent  data  views  encapsulating  specific  examples 
of  the  generic  SDEs  as  well  as  project  specific  data  elements  that  cannot  be  found  in  the 
Reference  Model.  The  model  contains  also  the  semantics  and  structure  of  the  metadata. 

The  NATO  Directory  Data  Model  has  been  adopted  by  the  NATO  Directory  Services  Working 
Group  (DSWG).  It  is  intended  to  support  interoperable  electronic  directory  services  across 
NATO.  The  NATO  Directory  Data  Model  is  expected  to  be  soon  included  in  the  NATO 
Corporate  Data  Model.  The  purpose  of  this  model  is  to  maintain  the  NATO  Directory  Schema 
that  covers  the  directory  data  types,  object  classes,  matching  rules,  name  forms  and  structure 
rules  that  are  necessary  to  specify  the  information  stored  in  the  Allied  Directory  System. 

The  main  interoperability  concepts  that  guide  the  NATO  data  models  include  the  architectural 
configurations  and  their  interoperability  profiles  (NATO-to-NATO  requirements),  and  the 
Information  Exchange  Gateways  (IEG)  (NATO-to-nation  requirements). 
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Recognizing  that  the  interoperability  problems  cannot  effectively  addressed  as  a  whole,  NATO 
emphasizes  the  need  to  refine  interoperability  approaches  by  introducing  the  concept  of 
degrees  of  interoperability.  The  degrees  help  to  categorize  how  operational  effectiveness  can  be 
enhanced  by  structuring  and  automating  the  exchange  and  interpretation  of  data.  The  degrees 
were  further  refined  into  sub-degrees  identifying  specific  interoperability  services. 

MIP  -  Standard  Data 

NATO’s  Multilateral  Interoperability  Program  (MIP)  has  the  goal  “to  achieve  international 
interoperability  of  Command  and  Control  Information  Systems  (C2IS)  at  all  levels  from  corps  to 
the  lowest  appropriate  level,  in  order  to  support  multinational,  combined  and  joint  operations 
and  the  advancement  of  digitization  in  the  international  arena,  including  NATO". 

The  main  idea  behind  the  MIP  data  interoperability  solution  is  to  standardize  the  specification  of 
the  inter-system  information  exchange  requirements.  The  participant  systems  agree  on  the 
meaning  of  the  exchanged  information,  with  no  mandated  impact  on  their  local  national  systems. 
The  MIP  concept  of  interoperability  is  based  on  the  exchange  of  standardised  data  elements  that 
use  agreed  and  common  data  identifiers.  The  approach  is  based  on  using  a  common  data 
interchange  model,  namely  the  Command  and  Control  Information  Exchange  Data  Model 
(C2IEDM).  The  role  of  C2IEDM  is  to  support  unambiguous  information  exchange,  or  data 
interoperability,  among  MIP  enabled  national  C2IS  systems. 

In  the  NATO  C3  perspective,  the  MIP  solution  aims  at  achieving  interoperability  degree  2.h 
(Structured  Data  Exchange/Data  Object  Exchange)  for  its  human-interpretable  information 
exchange  mechanism  and  degree  4.2  (Seamless  sharing  of  information/common  information 
exchange)  for  its  systems-interpretable  information  exchange  mechanism. 

The  C2IEDM  in  itself  cannot  express  all  the  constraints  that  prevent  its  wrongful  utilization. 
Thus  the  process  is  completed  by  adding  business  rules  and  constraints  expressed  informally  in 
natural  language  in  the  documentation  that  accompanies  the  formal  data  model.  The  resulting 
MIP  data  model  includes  the  formal  model  and  accompanying  documentation  in  natural 
language,  so  that  it  can  be  used  to  implement  in  a  consistent  manner  a  particular  solution  based 
on  this  model. 

C2IEDM  comprises  data  elements  describing  a  fairly  large  common  vocabulary  consisting  of 
176  information  categories  that  include  1500  content  elements.  In  general,  C2IEDM  describes  all 
elements  of  interest  on  a  battlefield,  such  as  organizations,  persons,  equipment,  facilities, 
geographic  features,  weather  phenomena,  military  control  measures,  etc.  This  is  also  known  as 
the  Generic  Hub.  In  addition  to  this,  special  functional  areas  are  defined,  extending  the  Generic 
Hub  under  national  responsibility  to  respond  to  the  national  concerns  needs  of  exchanging 
information. 

It  is  currently  used  as  the  core  data  model  for  various  C4I  systems,  and  as  a  reference  model  for 
various  simulation  systems.  It  also  could  be  used  by  other  information  exchange  mechanisms 
lacking  a  unified  information  structure,  such  as  message  formats. 
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The  procedures  and  documentation  required  to  implement  the  current  version  of  the  MIP 
interoperability  solution,  the  MIP  Baseline  2,  includes  the  MIP  Common  Interface  (MCI)  which 
specifies  how  an  interface  to  the  core  data  model  and  ARM  needs  to  be  constructed. 

The  MIP  Baseline  specifications  are  not  currently  based  on  commercial  standards.  Nevertheless, 
there  are  plans  for  an  XML  interface. 

NCES  -  Standard  Metadata 

Data  interoperability  is  at  the  core  of  the  DoD  Net-Centric  Data  Strategy  [DoDCIO].  The  NCES 
(Net-Centric  Enterprise  System)  will  provide  data  tagging,  searching,  and  retrieving.  The  focus 
is  on  establishing  metadata  standards.  This  approach  allows  for  standardizing  the  interpretation 
of  the  data  instead  of  the  data  itself,  as  it  was  the  case  with  previous  DoD  approaches  to  data 
interoperability.  The  efforts  go  to  establish  a  standard  description  in  the  form  of  standardized 
metadata. 
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Figure  1.  The  NCES  Architecture 

NCES  is  materialized  by  a  set  of  Core  Enterprise  Services  and  Community  of  Interest  (COI) 
capabilities  (Fig.  6).  The  services  provide  the  basic  ability  to  search  the  enterprise  for  desired 
information  and  then  establish  a  connection  producer-consumer.  Capabilities  are  organized 
around  communities  of  interest  such  as  C2,  Intelligence,  Logistics,  etc. 

COIs  are  established  based  on  data  organization  and  maintenance,  and  they  are  responsible  for 
the  data.  The  COIs  are  supposed  to  coordinate  and  align  along  some  guiding  principles,  without 
any  central  node.  Registries,  catalogs,  and  shared  spaces  provide  mechanisms  to  store  data  and 
metadata.  Metadata  describes  data  assets  and  the  use  of  registries,  catalogs,  and  shared  spaces. 
The  COIs  are  responsible  for  the  data,  and  establishing  metadata,  whereas  the  structure  and  the 
standards  will  be  coordinated. 

NCES  has  been  conceived  as  a  service  oriented  system,  and  this  architecture  paradigm  sets  its 
own  perspective  on  the  interoperability  solution.  Encapsulating  the  system  functionality  as 


148 


services,  as  the  building  blocks  of  the  system,  naturally  places  the  interoperability  problems  at 
the  service  boundaries. 

The  Mediation  Services  is  part  of  the  Core  Services,  and  provide  a  mechanism  to  disseminate, 
translate,  aggregate,  fuse,  or  integrate  data  and  associated  metadata  for  all  NCES  services.  The 
NCES  mediation  concepts  apply  to  data  as  well  as  metadata  and  services.  Several  types  of 
mediation  will  be  required  including  various  forms  of  data  mediation  and  service  mediation.  This 
paper  addresses  only  the  data  mediation  aspects. 

Mediation  is  one  of  the  key  NCES  capabilities,  and  it  is  based  on  the  existence  of  standard 
metadata.  Mediation  resolves  interoperability  problems  such  as  differences  in  the  name, 
structure,  representation,  and  meaning  of  data. 


Net-Centric  Capability  Pilot  (NCCP)  -  Standard  Data  Transformation 

The  NCC  Pilot  is  intended  as  a  showcase  for  a  set  of  capabilities  that  cover  the  Core  Enterprise 
Services  form  NCES,  C2  services  from  UDOP  (User  Defined  Operational  Picture)  and  NGC2 
(Next  Generation  C2)  Support  Services,  and  other  developing  Mission-oriented  services  under 
Global  Strike,  Situational  Awareness,  Intelligence,  etc.. 


Figure  2  NCCP  Scope 

The  NCES  provides  the  basic  set  of  services  for  all  communities  of  interest  (COIs).  The  core 
services  included  in  the  pilot  are  Information  Assurance  (IA)  Security,  Discovery,  Messaging, 
Mediation,  Storage,  and  Enterprise  Service  Management  (ESM). 

The  NGC2  Support  Services  are  shared  among  all  NGC2  mission  applications.  They  are  not 
specific  to  a  particular  community  of  interest.  Examples  of  these  services  are  process 
management  (including  process  orchestration)  and  workflow  services. 

The  C2  COI  services  are  specific  to  the  Command  and  Control  community  of  interest,  and  are 
shared  by  all  applications  across  that  community.  The  C2  COI  services  are  also  known  as  UDOP 
services.  Examples  are  report  management,  track  management,  and  entity  management. 
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Figure  3.  NCCP  Data  Mediation 

The  Situational  Awareness  services  provide  the  DoD  the  ability  to  integrate  all  information 
necessary  to  support  mission-specific  decisions  during  concurrent  planning  and  mission 
execution.  The  Global  Strike  is  a  specific  instantiation  of  the  Force  Employment  -  air  and  space 
mission  service.  It  involves  planning  and  execution  of  strategic  air  platforms  (B-52,  B-1B,  and 
B-2  aircrafts). 

The  NCC  pilot  is  based  on  service  oriented  architecture  (SOA)  and  is  implemented  using  Web 
Services.  There  is  a  strong  emphasis  in  using  open  standards  such  as  Hypertext  Markup 
Language  (HTTP),  Simple  Object  Access  protocol  (SOAP),  and  extensible  Markup  Language 
(XML).  In  some  cases,  legacy  systems  are  wrapped  by  Web  services. 

The  NCCP  Data  Mediation  Service  has  a  restricted  scope  (compared  to  the  general  requirements 
formulated  for  NCES)  and  is  defined  as  providing  “  the  ability  to  translate  XML  documents  from 
a  known  source  schema  to  a  known  target  schema  that  reside  in  the  DoD  Metadata  Registry 
using  XSL  mappings  stored  in  the  registry.  The  resulting  schema  can  be  another  XML  document, 
an  HTML  document,  or  any  text-based  document”. 

The  NCES  Data  Mediation  Service  is  basically  an  XML  transformation  service.  XML 
documents  are  transformed  between  NCES  services  using  XSLT.  The  XML  mappings  are  stored 
within  the  DoD  Metadata  Discovery  Services  (Fig  9). 


The  DoD  Metadata  Registry  (DMR)  is  used  here  as  the  standard  repository  of  XML  translations. 
For  the  next  releases,  there  are  plans  to  allow  the  consumer  service  to  denote  the  XSLT  to  be 
used  and  therefore  to  become  independent  on  the  DMR. 

The  translations  have  to  be  defined  at  the  design  time  between  each  pair  of  communicating 
services.  For  each  pair,  translations  have  to  be  defined  both  ways.  Defining  such  translations 
requires  understanding  of  both  data  models  and  also  familiarity  with  the  application  domains.  In 
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other  words,  although  this  approach  provides  the  advantages  of  simplicity,  adherence  to  open 
standards,  and  takes  advantage  of  an  existent  registry,  it  still  requires  considerable  human 
intervention. 

The  approach  taken  by  the  NCCP  pilot  can  be  classified  as  a  static  data  transformation  between 
each  pair  of  communicating  systems.  The  transformation  algorithms  are  defined  at  the  design 
time,  and  cannot  be  changed  dynamically  at  run  time.  Each  data  model  has  to  be  well  understood 
by  the  developers,  and  each  time  the  model  changes,  the  data  transformation  algorithms  need  to 
be  re-written.  The  development  and  maintenance  of  the  NCCP  data  transformation  service 
require  considerable  effort,  particularly  when  new  systems  are  added.  The  technical  approach, 
using  XML  and  XSLT,  remains  to  be  validated  by  relevant  practice.  Although  the  popularity  of 
these  technologies  is  overwhelming,  relying  only  on  them  can  create  scalability  problems  in  the 
case  of  large  data  models  or  complex  communication  schemes. 


Defining  Scalable  Models  -  basics 

We  need  a  data  model  that  specifically  addresses  the  interoperability  between  different  data 
models  at  more  abstract  levels.  Without  it  any  attempts  to  solve  interoperability  problems  risk  to 
be  inconsistent,  partial,  and  difficult  to  generalize  for  new  data  models.  We  need  a  model  that 
can  be  applied  to  all  data  operations  that  take  place  in  the  systems:  searching,  retrieving, 
accessing,  interpreting,  aggregating,  fusing,  mapping,  etc.  Most  data  models  were  invented  for 
operations  that  didn’t  involve  data  interoperability,  for  operations  such  as  accessing  and 
retrieving  from  known  data  sources.  Interoperability  issues  appear  when  data  sources  are  not 
necessarily  known,  and  when  the  format  and  content  of  data  are  different  or  even  unknown  at  the 
design  time. 

One  approach  to  address  the  complexity  of  such  encompassing  data  model  is  by  defining  levels 
(or  layers)  of  data  interoperability.  This  is  not  by  any  means  a  new  type  of  approach.  It  can  be 
found  in  the  network  and  web  protocols  (TCP,  IP,  HTTP,  SOAP,  etc.),  or  in  the  semantic  web 
data  language  stack  (XML,  RDL,  OWL,  etc.).  What  makes  this  approach  different  is  its 
application  to  data  modeling.  [Melnik2000]. 

In  this  paper  we  are  referring  to  the  data  mediation  issues,  but  this  approach  can  apply  to  other 
services  as  well.  The  objective  of  this  approach  is  to  provide  a  clear  distinction  between  data 
mediation  services  offered  at  different  levels.  The  services  can  be  layered  on  top  of  each  other, 
enabling  a  stack  of  services  on  top  of  more  basic  levels. 

The  main  idea  is  to  separate  data  from  its  usage  by  creating  intermediate  layers  of  data 
descriptions,  or  metadata.  The  metadata  can  describe  both  the  data  structure  and  its  usage.  The 
applications  access  data  indirectly,  by  using  the  associated  metadata.  If  more  than  one 
application  will  access  the  same  data,  then  the  metadata  has  to  be  represented  in  a  common  or 
standard  way,  so  that  all  applications  can  understand  it. 
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From  a  theoretical  point  of  view,  there  are  at  least  three  different  levels  of  abstraction  for  data 
modeling:  structural,  ontological  and  operational.  At  each  level  data  models  can  be  constructed 
and  expressed  by  using  specific  languages  and  tools. 


Structural  Level 

At  the  structural  level,  the  data  model  comprises  sets  of  elementary  syntactic  data  elements  that 
are  composed  in  arbitrary  higher  level  structures,  so  that  data  can  be  efficiently  accessed  and 
retrieved.  The  reasons  why  data  has  been  organized  in  certain  ways  are  not  explicitly  contained 
in  the  model.  The  data  structuring  reasons  or  data  semantics  is  implicitly  represented  by  the 
processes  that  use  the  data.  Any  applications  that  exchange  information  at  the  structural  level 
needs  to  preserve  the  initial  structure,  so  that  the  information  can  be  meaningfully  exchanged 
back  and  forth. 

One  of  the  most  efficient  and  simple  syntactic  mechanisms  to  structure  data  is  tagging  (or 
naming)  data.  This  is  done  by  using  markup  languages.  XML  (extended  Markup  Language)  has 
become  pervasive,  its  use  extending  really  beyond  its  initial  goal  of  describing  web  pages.  To 
reconstruct  exchanged  data  objects  and  their  relationships  used  in  the  structural  layer,  the 
description  of  the  data  structure  is  obviously  necessary.  Rather  than  writing  application  code  to 
interpret  each  particular  structure,  a  standard  (semi-)  structure  description  language  can  be  used 
instead.  For  example,  the  XML  schema  language  can  be  used  as  the  standard  for  describing  or 
documenting  the  data  structures. 

Mediation  at  the  structural  level  transforms  data  having  the  same  meaning  from  one  syntactic 
representation  to  another.  The  data  structures  may  have  the  same  names  but  differently  arranged, 
or  they  may  have  different  names,  but  a  mapping  is  always  possible. 

The  data  mediation  services  offered  at  the  structural  level  is  basically  data  transformations 
between  different  representations.  Mapping  data  from  multiple  and  diverse  sources  into  different 
data  formats  represents  a  basic  set  of  functionality.  The  semantically  correct  and  complete 
creation  and  interpretation  of  the  mappings  is  a  highly  nontrivial  process.  The  mapped  models 
include  structured  models  such  as  relational  or  object  oriented,  and  semi-structures  such  as 
XML.  The  current  state-of-the-art  of  the  technology  for  such  mappings  is  represented  by  tools 
that  generate  trivial  mappings  across  relational  schemas,  the  users  having  to  manually  identify 
and  specify  some  more  difficult  or  impossible  to  automate  details. 


Ontological  Level 

Semantic  interoperability  requires  standards  not  only  for  the  syntactic  form  of  the  data  but  also 
for  the  semantic  content.  The  semantic  models  include  explicit  descriptions  of  the  data  elements 
semantics.  Semantic  data  models  emerged  from  the  requirement  of  having  more  expressive 
conceptual  data  models.  The  semantic  models  are  always  considered  as  such  by  comparison  with 
some  other  models  that  capture  less  information  about  the  application  domain. 
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The  semantic  models  have  been  recently  denoted  as  ontologies,  following  the  Semantic  Web 
terminology.  An  ontology  constitutes  a  formally  defined  and  represented  encyclopedia  on  a 
given  subject  domain.  The  ontology  spectrum  varies  from  controlled  vocabularies  to  highly 
specialized  domain  models.  Ontologies  are  application  independent,  specified  in  a  standard 
modeling  language.  Formal  ontologies  are  specified  using  representations  languages  that  can  be 
used  for  automated  reasoning.  For  instance,  the  Semantic  Web  language  for  ontologies  is  OWL 
[OWLSpec], 

Due  to  their  formal  representation  (here  formal  means  machine  understandable),  ontologies  are 
data  models  that  can  be  reused  across  systems  and  applications.  Their  distinctive  feature  is  to 
address  the  interoperability  problems  at  a  higher  degree  of  abstraction. 

In  fact,  both  syntactic  models  and  semantic  models  are  simultaneously  needed,  not  in  the  least 
due  to  the  fact  that  they  serve  very  different  purposes.  The  semantic  models  provide  domain 
abstractions,  while  syntactic  models  enforce  structure  on  the  information  sources.  There  is 
always  a  degree  of  overlap  between  the  two  approaches,  as  the  semantic  models  of  the  day 
become  the  syntactic  models  of  yesterday  (XML  has  been  introduced  as  the  miracle  semantic 
tool  at  the  time),  and  as  a  result  it  is  sometime  confusing  to  clearly  separate  the  two. 

Operational  Level 

Interoperability  at  the  ontological/semantic  level  is  not  always  possible.  The  question  is  what 
degree  of  semantic  overlapping  is  necessary  to  achieve  interoperability  between  two  systems. 
The  answer  can  be  given  by  the  specification  of  the  operational  need  for  interoperability. 

For  instance,  military  interoperability  occurs  when  different  military  services  (air,  navy,  land)  act 
in  a  combined  fashion  and  also  in  the  international  context  of  coalitions.  Each  developed  C2 
systems  that  suit  their  specific  needs.  They  share  some  elements  that  might  be  shared  by  their 
distinct  ontologies.  The  shared  elements  may  be  represented  differently,  but  they  do  exist  in  both 
systems.  For  instance,  in  their  respective  ontologies,  the  details  about  the  spacecraft  types  may 
differ  from  the  land  component  to  the  navy  component.  These  information  elements  cannot  be 
exchanged  as  such.  Therefore,  the  mapping  process  has  to  determine  that  there  is  sufficient 
conceptual  compatibility  between  the  information  elements,  so  that  they  can  be  safely  used.  The 
operational  context  is  the  driving  force  and  rationale  for  this  kind  of  semantic  interoperability.  In 
other  words,  the  mapping  can  be  considered  acceptable,  provided  that  the  operational  concept  is 
still  conveyed  between  the  systems. 

NOTE:  It  is  very  important  to  establish  standard  connections  between  data  modeling  levels. 


Conclusions 

Achieving  data  interoperability  is  a  highly  non-trivial  process.  Different  interoperability  contexts 
come  with  different  interoperability  problems,  which  at  their  turn  may  be  solved  using  different 
methods  and  tools.  Various  models  for  data  interoperability  can  coexist  and  in  fact  should 
coexist  within  a  complete  solution.  The  challenge  is  to  appropriately  define  levels  or  layers  of 
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interoperability  within  a  given  system,  from  no  interoperability  at  all  to  highly  complex 
interoperability. 
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Aim:  Achieve  international  interoperability  of 
Command  and  Control  Information  Systems 
(C2IS)  at  all  levels: 


-  Corps  to  battalion,  or  lowest  appropriate  level 

-  Support  multinational,  combined  and  joint  operations 

-  Advance  digitization  in  the  international  arena  including 
NATO 


Scope: 


-  War  Ops,  Crisis  Response  Ops,  Defence  Against  Terrorism 

-  Joint,  Interagency,  Multinational,  Non-governmental 
Organizations 

-  Tactical  to  Operational  and  Strategic  levels 
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MIP  Defined 


Multilateral  Interoperability  Programme 


What  it  is  and  what  it 
provides: 

-  Materiel  /  Combat 
developer  forum  Driven 
by  national  doctrine  and 
requirements 

-  Venue  for  international 
interoperability  testing 

-  Coordinates 
synchronization  of 
materiel  fielding  plans 

-  System-independent 
capability  based  on 
information 
interoperability 
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MIP  Defined 


Multilateral  Interoperability  Programme 


•  What  it  is  not: 


-  A  typical  cooperative 
development 
program: 

•  No  common  funding 

•  No  single  Program 
Manager 

•  No  common 
hardware  or  software 
development 

-  Organization  specific, 
e.g.,  NATO,  PFP, 
ABCA . .  . 


Bottom  Line:  MIP  is  a  functioning  successful  C2  Community  of  Interest 
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Current  MIP  Membership  - 
Corps  &  Below  C2IS 
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MIP 

Working  Groups 


Multilateral  Interoperability  Programme 
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Chair 
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Data  and 
Procedural 
Working  Group 
|*|  (DPWG) 


Technical 
Working  Group 
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Multi-Disciplinary 
Working  Parties 
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Foundation  for  the  MIP  Process 


MIP  Requirements 
Roadmap 


1  In  Blodc  1 ,  new  requirements  Blort  2  |  |  |n  blodl  1 .  no  planned  block  2  wot 

HIP 

Requirements 

Multilateral  Interoperability  Programme 


MIP  has  a  long-term  plan  to  deliver  capability 


Police 
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Block 

Implementation  Plan 


Multilateral  Interoperability  Programme 


Block  1 

Warfare  Ops  /  SA 


Block  2 

Crisis  Response 
Operations 

Block  3 
Joint 


Today 


Concept 


Multilateral  Interoperability  Programme 


Effective  C2  for  international  operations 


Shared  tactical  pictured 


/^'T^utomated  information" 


exchange 


Implementation 


MCI 


Common 

Information  Model 


National 


Collaboration 


Common  understanding 
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Staff 

officer 


I 
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Commander 
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Concept  - 
C2IEDM 


Multilateral  Interoperability  Programme 


GH  ^  LC2IEDM  ^  C2IEDM  ^ 
JC3IEDM 

Automated  C2  Interface  Exchange 
Mechanism  To  Support  Liaison  and 
Automation 

-  Exchange  Of  Orders/Graphics 

-  Holdings/Status  Information 

•  e.g.,  AD  Weapons  Control  & 
Running  Status 

Operational  exchange  standards 
use  a  common  vocabulary 
consisting  of  176  information 
categories  that  include  over  1500 
content  elements. 

Information  Exchange  Data  Model 
Serves  as  a  Hub  for  functional 
areas 

CRO  &  Joint  lERs 


11 


MIP 

Path  Forward 


Multilateral  Interoperability  Programme 


•  MIP  has  established  a  basic  capability  for 
exchange  of  SA  data  in  Block  1 

•  MIP  has  a  path  forward  based  upon  a  defined 
set  of  functionality  enhancements  in  a  block 
implementation  scheme 

•  We’ve  identified  the  need  to  define  MIP 
Operating  Procedures  that  need  to  be 
incorporated  into  national  unit/TOC  SOPs 

•  We’ve  begun  to  realize  the  impact  on  ways  of 
doing  business/culture 

•  Need  to  investigate  and  plan  for  evolution  in 
warfare  in  the  information  age 
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MIP  Acceptance 


Multilateral  Interoperability  Programme 


NATO  Corporate 
Data  Model 


BiSC  AIS 

NATO  C3 

Land  Functional 

Technical 

Services 

Architecture 

NATO 

Force  Goal 

MIP 

HRF(L)  HQ 
Military  Criteria 

NATO 

Standardisation 

Agreement 

NATO  Policy 

National  C2IS 

MIP  has  Gained  Wide  Acceptance  within  NATO  as  a  Foundation 
for  Policy,  Standards,  Specifications  and  Systems! 


Other  US  Stakeholders  - 
Efforts  that  Leverage  MIP 

•  GIG 


Multilateral  Interoperability  Programme 


-  J6I  has  identified  C2IEDM  /  MIP  addresses  Key  Interface  Profile  #17 

-  Identified  as  applicable  to  User  Defined  Operational  Picture  (UDOP)  COI 

•  ABCS 


-  Current  US  MIP  implementation  program  is  Maneuver  Control  System 

-  Implementation  on-going  in  MCS  6.4  GE 

-  Planned  software  reuse  -  other  ABCS  programs 

•  Army  Future  Combat  Systems  (FCS) 

-  MIP  can  be  leveraged  to  satisfy  coalition  interoperability  requirements 

-  C2IEDM  integral  to  FCS  data  strategy 

-  MIP  FCS  MOA  in  process. 

•  FIOP  FY04  program  initiative 

-  Single  Integrate  Ground  Picture  (SIGP) 

-  Situational  Awareness  Data  Interoperability  (SADI) 

•  Shared  Tactical  Ground  Picture  (STGP) 

-  US,  UK  and  Norway  interoperability  project 

-  MIP  listed  as  “Quick  Win” 

•  DISA  XML  Registry:  Coalition  Namespace 

•  CIO/G-6:  C2IEDM  foundation  for  Data  Strategy 

•  Foundation  piece  of  the  DJC2/JC2  Strategy 
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www.  m  ip-site,  org 


Multilateral  Interoperability  Programme 


-  15 

AT&L 
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The  C2  Community  of  Interest  (Col)  as  the  Foundation  for  Joint, 
Multinational,  and  Inter-agency  Interoperability 


Erik  Chaum 

Naval  Undersea  Warfare  Center 
Newport,  Rhode  Island 
ChaumE@NPT.NUWC.Navy.mil 


Good  afternoon,  it’s  my  pleasure  to  be  here  today  to  help  discuss  interoperability  and  in 
particular  why  the  many  and  varied  military  functional  communities-of-interest  (Col)  must  build 
on  a  common  Command  and  Control  (C2)  core  set  of  concepts  and  semantics.  Interoperability  is 
a  fundamental  capability  required  in  net-centric  operations,  military  systems  and  services.  I  am 
going  to  assert  that  the  work  of  the  Multilateral  Interoperability  Programme  (MIP)  and  in 
particular  the  Command  and  Control  information  Exchange  Data  Model  (C2IEDM)  can  serve  as 
a  baseline  for  joint,  multinational  and  interagency  C2  interoperability. 


NEWPORT 


Presentation  Themes 


•  They  way  things  are 

•  The  way  we  want  things  to  be 

•  Implications 


To  do  this,  let’s  consider  how  things  are,  how  we  want  them  to  be,  and  the  implications  that 
arise. 

I’ll  start  with  a  question;  what  part  of  the  house  is  most  important  the  foundation,  the  walls,  or 
the  roof?  In  truth  they  are  all  important;  they  all  have  to  be  well  designed,  they  all  have  to  be 
well  built,  and  they  all  have  to  be  well  integrated.  Which  one  do  you  build  first?  The  message, 
there  are  usually  many  important  parts  to  any  endeavor  but  determining  and  establishing  the 
foundational  parts  first  is  critical!  The  net-centric  operations/warfare  (NCO/W)  future  that  we 
are  working  to  build  is  completely  dependent  on  getting  interoperability  right.  Getting  it  right 
will  mean  getting  it  fundamentally  different!  This  is  in  large  part  why  the  US  Department  of 
Defense  vision  speaks  about  transformation  and  not  just  change. 

Interoperability  is  an  operational  and  technical  quality  that  enables  entities  to  effectively  and 
efficiently  works  together.  At  a  most  fundamental  level,  interoperability  requires  a  capability  to 
unambiguously  exchange  and  correctly  process  information.  The  essence  of  being  networked 
requires  both  a  capability  to  communicate  and  understand  -  otherwise  you  are  on  the  network  but 
not  networked.  These  two  capabilities  are  required  within  any  entity  (man  or  machine)  that 
expects  to  participate  in  a  distributed  integrated  process,  e.g.,  military  functional/mission 
operations. 
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Interoperability 


*  Interoperability  is  an  operational  and  technical 
quality  that  enables  entities  to  effectively  and 
efficiently  work  together. 

*  At  its  most  fundamental  level,  interoperability 
requires  a  capability  to  unambiguously 
exchange  and  correctly  process  information 
(being  networked). 

*  Joint  vision;  ubiquitous  interoperability, 
automated  information  exchange,  and  smarter 
applications/autonomous  entities 

•  Good  decision-making  requires  knowledge  of,  and 
the  ability  to  reason  about,  operational  context 


When  I  first  read  and  was  trying  to  understand  the  DoD  Joint  Vision,  I  learned  that  the 
envisioned  capability  was  dependent  in  large  part  on  1)  ubiquitous  interoperability,  2)  automated 
information  processing,  and  3)  smarter  and  more  useful  warfighter  decision  support  (which 
might  be  manifest  as  intelligent  agents,  applications,  or  autonomous  systems).  The  Joint  Vision 
seeks  to  use  information  technology  to  achieve  these  three  complementary  capabilities.  The 
much-touted  faster,  smaller,  cheaper  processors  and  network  hardware  alone  will  not  provide  the 
desired  set  of  capabilities.  So  what  is  required  to  achieve  the  vision? 

Warfighters  require  knowledge  of  the  operational  context  in  which  they  operate  in  order  to  make 
well-informed  and  appropriate  decisions.  Thus,  it  follows  that  sophisticated  decision  support 
systems  (regardless  of  type)  will  also  require  access  and  the  ability  to  process  operational  context 
information/knowledge.  Therefore  the  envisioned  future  net-centric  warfare  capabilities  depend 
in  significant  part  on  our  ability  to  formally  represent  and  share  operational  context 
information/knowledge  between  warfighters  and  with  and  between  our  decision  support  systems. 
In  the  NCO/W  environment  “sharing”  explicitly  requires  the  automated  ability  to  process  the 
information  exchanged  even  when  it  comes  from  a  priori  unknown  sources. 

As  an  example,  sensor-derived  track  data  is  absolutely  essential  and  completely  insufficient  to 
conduct  coordinated  air  defense  operations.  A  decision  support  system  to  aid  a  Tactical  Action 
Officer  should,  before  it  recommends  a  specific  tactical  engagement,  know  if  “weapons  are 
free”,  what  air  space  coordination  measures  are  in  effect,  the  air  tasking  orders,  local  commercial 
airline  transit  routes  and  schedules,  reported  friendly  aircraft  and  ships  tracks,  other  organic  and 
off-board  track  reports/estimates,  the  status  of  other  air  defense  capable  forces,  and  many  other 
contextual  factors.  Much  of  this  and  other  relevant  contextual  information  will  come  from  off- 
board  the  ship,  from  Naval,  Joint,  multinational  and  international  sources. 

How  then  do  we  represent  and  share  operational  context?  If  we  can’t  do  it  effectively  then  our 
ability  to  cooperate,  interoperate,  and  synchronize  will  be  limited  and  the  vision  will  remain 
unrealized. 
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They  way  things  are 


*  To  build  military  collective  capability 
we  train  military  personnel 

■  Core  +  specialty  training 

■  Community  then  Service  then  Joint 

*  To  build  military  collective  capability 
we  integrate  information  systems 

■  Expensive  to  build  and  maintain 

■  Ambiguous  and  incomplete  information 
exchanges  limit  effective  interoperability 

■  Unstructured  exchanges  limit  aided 
information  processing 


How  do  we  build  interoperability  today?  To  start  with  we  build  military  communities  by  training 
personnel  to  give  them  a  shared  understanding  of  domain  knowledge;  a  shared  set  of  operational 
concepts,  semantics,  and  key  domain  relationships.  There  are  core  sets  of  ideas  that  all  military 
personnel  learn,  e.g.,  military  ranks,  the  concept  of  the  commander  and  subordinate,  etc. 
Functional  area  training  builds  on  the  core  domain  knowledge.  By  going  through  the  same 
schools  and  processes  we  develop  a  military  team  that  is  prepared  to  effectively  work  together. 

Fielding  military  capability  requires  integrating  systems  and  that  is  typically  expensive  to  do  and 
maintain.  To  build  a  successful  and  robust  interface  between  two  systems  a  well-defined 
interface,  strictly  adhered  to  by  both  systems,  must  be  established.  It  must  precisely  define  what 
will  be  shared,  what  it  means,  and  what  business  rules  are  associated  with  the  information  and 
the  business  process/protocol.  If  either  side  doesn’t  fully  appreciate/understand  it,  or  correctly 
implement  the  interface,  then  eventually  that  system,  and  associated  process,  will  fail  under  some 
condition.  This  is  just  as  true  in  today’s  service  oriented  architectures  as  it  is  in  a  point-to-point 
interface. 


Consensus  Today 


*  Consensus  is  today,  as  it  has  always 
been,  the  basis  for  any  robust  interface. 

■  A  software  interfaces  must  be  well  defined  and 
adhered  to  in  order  for  it  to  function  reliably. 

■  Consensus  must  be  built. 

■  Technical  consensus  is  limited  by  choices 
made  during  the  design  process.  Thus, 
interoperability  is  likewise  limited. 

•  Types  of  exchanges: 

■  Lossless 

■  Incomplete  (dark  metadata) 

■  Information  lost 


165 


Which  data  and  operational  context  information  can  be  exchanged  between  any  two  systems  is 
determined  by  what  those  systems  know  how  to  represent,  i.e.,  entities  can  only  effectively 
communicate  that  which  both  understand.  In  this  “information  space”  overlap  ambiguous  and 
incomplete  information  exchanges  are  however  prevalent.  Limited  interoperability  is  likely  to 
occur  when  systems  are  built  on  different  semantic  baselines. 

There  are  only  two  results  when  exchanging  information,  either  the  information  passed  is 
completely  and  properly  understood,  or  not.  When  the  exchanged  information  is  not  completely 
understood  it  can  be  due  either  to  filtering  (“dropping”  what  is  not  understood)  or 
misinterpretation. 


No  Consensus,  Lost  Information 


*  Classification 
Uncertainty: 

■  System  A: 

♦  Probability-based 
declaration 

■  System  B: 


System  A 


♦  Single  type 
declaration 

System  B 

o 

Information  lost 

-Jjfcv 

o 

when  System  A 

o 

sends  to  System  B 

• 

As  an  example,  consider  two  data  fusion  systems  each  of  which  has  independently  developed  a 
way  to  represent  the  concept  of  track  classification  uncertainty.  In  system  Alpha  track 
classification  uncertainty  is  represented  using  a  probability  construct,  e.g.,  Track  S001  is  a  vessel 
of  submarine  type  p=60%,  surface  craft  type  p=30%,  unknown  type  p=10%.  In  system  Beta  track 
classification  uncertainty  is  represented  as  one,  and  only  one,  option  from  an  enumerated  list, 
e.g.,  options  are  unknown,  air,  surface,  or  submarine.  Both  of  these  representation  concepts  and 
semantics  are  fine  on  their  own.  However,  when  system  Alpha  tries  to  send  “Track  S001  = 
60:sub/30:surf/10:unk”  to  system  Beta  what  happens?  Information  is  lost!  There  is  no  loss-less 
result  possible  because  the  concepts  and  semantics  within  the  two  systems  are  not  equivalent. 
Additionally,  limited  interoperability  is  likely  to  result  in  higher  integration,  testing,  and 
updating  costs. 

In  the  previous  simple  example  we  see  why  DoD  is  working  to  move  away  from  point-to-point 
(i.e.,  system  unique  interfaces)  and  to  functional/mission  Col-defined  domain  concepts  and 
semantic  standards.  In  a  Col  standards-mediated  world,  the  warfighters  define  the  relevant  Col 
concepts  and  semantic  needed  and  all  Col  systems  and  services  implement  to  the  Col  standards. 
Conforming  systems  use  the  Col  data  model,  metadata,  taxonomies,  and  ontologies,  and  are  by 
design  compatible  at  the  semantic/information  level.  They  are,  in  this  critical  respect,  ready  to 
interoperate  and  deliver  capability  as  part  of  a  distributed  integrated  Col  warfare  process. 
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Today’s  Myths 


•  Our  system  engineering  experience  has 
led  us  to  believe  a  number  of  myths: 

■  Translation  /  mediation  are  good  enough 
for  exchanges  between  most  systems 

■  There  is  only  a  small  common  core  of 
information  that  everybody  requires. 

■  Standards  haven’t  worked 

■  XML  is  the  answer 

*  A  fundamentally  better  outcome  will 
result  from  the  same  repeating  the 
status  quo. 


Translation,  or  mediation,  may  seem  like  a  reasonable  alternative  to  a  difficult  consensus  process 
and  seeking  semantic  alignment  within  Cols.  DoD’s  net-centric  enterprise  services  (NCES) 
include  a  mediation  service  concept  -  a  service  that  converts  from  one  representation  to  another. 
Where  formal  lossless  translations  exist  (e.g.,  JPEG  to  TIFF)  mediation  is  practical  and  useful. 
However,  much  of  the  time  as  in  the  track  classification  uncertainty  case  above,  mediation  will 
not  provide  fully  acceptable  results.  In  the  short  run,  as  legacy  systems  evolve  to  comply  with 
Col  standards  they  will  translate  to  communicate  and  the  limitations  discussed  above  will  apply. 
In  the  longer-term,  the  Col-approach  requires  semantic  alignment  at  the  interface  and  internal  to 
systems  and  services. 

What  is  the  scope  of  the  information/operational  context  that  we  need  to  understand  and 
exchange?  Is  it  a  small  or  large  set  of  information?  The  consensus-based  standardization  efforts 
of  the  Multilateral  Interoperability  Programme  (MIP)  give  us  an  important  “data  point”.  In  the 
MIP  experience  diverse  Army  communities  did  not  a  priori  believe  they  would  have  much  in 
common.  The  consensus  process  led  to  the  realization  that  there  is  perhaps  as  much  as  a  90% 
overlap.  In  other  words,  there  is  a  large  common  core  of  military  operational  context 
information/knowledge  that  all  commanders  need  to  share  in  order  to  conduct  effective 
coordinated  operations. 

Why  haven’t  previous  standards  worked  to  achieve  interoperability?  Standard  do  work, 
however,  there  are  many  aspects  to  standards  specification,  interpretation,  and  implementation 
that  can  lead  to  technical  failure.  Perhaps  equally  important  there  are  many  organizational, 
business,  and  social  aspects  to  standards  development  and  adoption  that  can  prove  to  be 
impediments.  There  is  no  substitute  for  standards,  however,  in  the  NCO/W  environment  we 
require  a  new  standards  paradigm  to  ensure  that  dissimilar,  distributed,  systems  and  services  can 
be  integrated/composed.  Internet  IP  protocols,  and  service-oriented  architectures  are  part  of  the 
solution.  System-independent  Col  information  exchange  standards  are  equally  a  critical 
foundational  layer  in  our  new  enterprise  paradigm/architecture. 


167 


The  MIP  2003  Integrated  Operational  Test  &  Evaluation  (IOT&E)  was  an  example  of 
interoperability  based  on  system-independent  Col  information  exchange  standards.  During  the 
IOT&E  twelve  Army  operational  and  tactical  systems  from  eleven  countries  were  integrated  and 
tested.  Each  of  these  systems  was  built  independently  to  national  functional/mission 
requirements.  Underlying  this  impressive  Col  capability  was  a  twelve-year,  24  nation,  ~$100 
million  (each  nation  funded  their  own  participation)  effort  to  build  operational  and  technical 
consensus.  What  is  different  and  important  about  the  MIP  effort  is  that  the  investment  is  not 
locked  inside  a  few  proprietary  systems  and  unique  interfaces,  but  rather,  it  is  published  for  reuse 
as  an  open  international  standard.  DoD  can’t  afford  to  start  over  and  we  need  to  be  interoperable 
with  our  allies.  Thus,  we  must  consider  the  work  of  the  MIP  as  an  important  point  of  departure 
for  both  Combined  and  Joint  interoperability. 

Extensible  Markup  Language  (XML),  much  touted  as  the  new  lingual  franca,  is  not  a  complete 
interoperability  answer.  XML  provides  a  syntax  What  is  more  important  is  the  domain 
namespace.  The  domain  namespace  definition  process  requires  a  community  to  build  consensus 
on  what  concepts  and  semantics  are  important  to  the  community,  its  business  processes  and 
supporting  information  exchanges.  The  MIP’s  multinational  process  has  built  such  a  consensus 
and  documented  it  using  the  C2IEDM  (along  with  the  thousand  pages  of  accompanying 
documentation).  The  C2IEDM  effectively  documents  a  domain  namespace  and  in  turn  can  be 
used  to  autogenerate  the  corresponding  XML  namespace  schema  (XSD).  With  regards  to  XML, 
the  hard  part  is  the  semantic  consensus  process  and  the  easy  part  is  the  XML  (XSD)  definition. 
To  alternatively  implement  system-unique  XML  schema  is  to  reinvent  the  point-to-point 
translation  approach,  i.e.,  XML  does  not  solve  the  “Alpha  to  Beta”  interoperability  problem 
described  earlier. 


The  way  we  want  things  to  be 


*  Information  age  concepts  and  capabilities 
applied  to  warfighting  &  business  operations 

*  C2  agility  and  mission  tailoring 

■  Joint  and  Combined 

*  Ubiquitous  information,  &  knowledge  sharing 

■  Task,  Post,  Process,  and  Use  (TPPU) 

■  Discovery  and  Pull 

■  Interoperability  through  “data”  and  meta-data 
standardization  [multi-national,  joint,  interagency] 


Improved  Coordination  of  Forces  /  Coordinated  Operations 


An  underlying  joint  and  combined  capability  objective  is  to  improve  our  ability  to  effectively 
coordinate  and  synchronize  diverse  forces,  from  the  operational  to  tactical  level.  Information 
technologies  and  concepts  are  applicable  to  the  way  DoD  does  business.  We  expect  these 
technologies  to  enable  capabilities  that  empower  the  warfighter  and  war  fighting  process  in  part 
through  greater  operational  and  tactical  agility  and  flexible  mission  tailoring.  Ubiquitous 
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information  and  knowledge  sharing  will  be  realized  through  a  new  set  of  services  that  enable 
entities  to  post  and  discover  Col  information  in  a  timely  manner.  To  get  this  fundamentally  better 
interoperability  outcome  we  need  a  fundamentally  better  joint  and  multinational  information 
exchange  consensus  definition  process. 


JU4tSE4 


Transformation 


•  Start  with: 


WMMM 


■  People 

■  Process 

■  Policy 

GIG  (and  WWW)  “Data”  Strategy: 

■  Community  of  Interest  (Col) 

♦  Shared  ontology,  data  models,  metadata, 
taxonomies,  schemas,  business  rules 

♦  Shared  semantics  and  domain  values 

♦  Externalizing  and  reusing  domain  knowledge 


■  Understandable  (Semantics  and  Syntax 
understood  by  applications  and  user) 


“Transformation”  is  a  DoD  watchword  today  and  is  intended  to  convey  the  expectation  that  we 
will,  as  an  organization,  be  fundamentally  different  and  better  after  the  change.  Joint  vision,  net- 
centric  warfare,  GIG,  and  FORCEnet  are  all  intimately  coupled  to  this  envisioned 
transformation.  They  are  not  so  much  different  futures  as  they’re  different  views  on  the  same 
objective  future.  The  published  GIG  data  strategy  for  realizing  interoperability  is  to  organize 
about  the  concept  of  communities-of-interest,  instead  of  about  systems.  As  already  mentioned, 
this  is  very  similar  to  the  World-Wide-Web  Committee  (W3C)  XML  namespaces  concept.  The 
GIG  data  strategy  is  explicitly  based  on  Cols  and  specifically  shared  data  models,  ontologies, 
metadata,  and  taxonomies.  The  development  of  shared  semantics  and  domain  values  is  a  critical 
part  of  publicly,  and  in  a  system-independent  manner,  defining  and  reusing  domain  knowledge. 
It  can  serve  as  a  basis  for  open  source  components  reducing  development,  testing,  and 
integration  costs.  It  also  enables  a  key  objective  of  the  data  strategy  that  is  to  create  semantics 
and  syntax  that  can  be  understood  by  both  the  warfighter  and  the  decision  support  applications. 


DoD  Data  Strategy  Goals 


*  Information  Interoperability: 

•  Increase  use  of  enterprise  and 
community  data 

♦  Visible 

♦  Accessible 

♦  Institutionalize 

♦  Trusted 

■  Decrease  use  of  private  &  system  data 

♦  Use  Col  standards  to  publish  on  the  GIG 

■  How  do  Col  interact  /  interrelate? 
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The  GIG  data  strategy  interoperability  goals  also  include  making  information  more  1)  visible,  2) 
accessible,  3)  institutionalized  and  4)  trusted.  To  do  this  we  must  at  the  same  time  make  it  less 
proprietary  and  system-specific  and  instead  migrate  to  Col  standards  -  which  will  address  the 
first  three  objectives.  Sharing  the  rich  set  of  operational  context  information  through  Col-based 
services  will  enable  developers  to  build  a  new  and  more  useful  generation  of  mission 
capabilities. 

But  how  do  the  various  Col  interact  and  or  interrelate? 


Implications 


*  Consensus-based  standards 

■  No  system,  Service,  or  process  is  an  island 

•  Translation  for  current  capabilities  is  a  transitional 
step,  fuller  semantic  alignment  &  reuse  is  the  goal. 

•  Service,  application,  process,  information  service, 
technology,  vendor  independent  information 
exchange 

♦  Shared  information  services 

-  Business  value  added: 

♦  Little  value  in  unique  battlespace  representations 

♦  High  value  in  being  able  to  exploit  and  reason  about  the 
community  view. 

•  But  is  there  one  standard? 


In  our  net-centric  world,  no  system,  service,  or  process  is  an  island.  Each  must  interoperate  with 
other  Col  capabilities  on  the  network.  Ideally,  no  semantic  translation  should  be  required 
enabling  easy  and  correct  processing  of  information.  In  turn  this  helps  ensure  that  integrated 
distributed  mission  capabilities  can  be  seamlessly  composed.  In  our  transformed  world 
commercial  entities  can  make  money  by  enabling  systems  and  services  to  successfully  join  and 
support  functional/mission  Cols.  In  a  Col-organized  world  building  unique  battlespace 
representations  and  information  exchange  interfaces  is  a  low  value-added  activity.  The  high 
value-added  activities  are  learning  the  Col  semantics  and  applying  operational  context  to  better 
meet  warfighter  decision  support/system/service  needs.  Note  that  within  a  given  system  the 
“physical”  representation  of  the  Col  data  model  (and  other  Col  standards)  can  be  tailored,  as  is 
required,  to  meet  the  implementation  needs  of  the  application  or  user.  Thus,  the  Col  approach 
does  not  limit  a  developer’s  local  design  choices,  except  at  the  interface  where  interoperability 
must  dominate. 

Can  there  really  be  one  standard  Col?  No,  but . . . 
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C2  as  the  Foundation: 
Mission  Cols  Build  on  a  C2  Core 


Humanitarian 


Personn 


Planning 


C2  Core  Littoral  Operations 


Logistics 


The  C2  Col  forms  a  foundational  core  on  which  each  functional/mission  community  must  build. 
Each  functional/mission  community  must  reuse  elements  of  the  C2-core  and  extended  the  core, 
where  required.  The  rationale  for  this  is  simple  and  straightforward  -  the  joint  and  combined  war¬ 
fighting  commander  needs  to  use  C2  to  efficiently  integrate  and  coordinate  all  of  his  mission 
capabilities.  Thus,  all  subordinate  commanders  must  understand  and  be  able  to  converse  using 
these  C2-core  concepts  and  semantics.  It  is  this  core,  or  foundational,  semantic  baseline  that 
integrates  all  functional/mission  Cols.  The  C2-core  must  be  reused  or  each  Col  will  create  an 
unwanted  Col  “stovepipe”. 


Joint  Command  and  Control  (JC2) 

Operational  Concept 


Mission  Capability  Packages 
Situational  Awareness 

Air  &  Space  Ops 

JC2  Mluim  Capabililin  r  r 


e>< -  ^ 

W  a 


Intelligence 

Force 


Core  C2  Services 

MIP  Core  C2 
Vocabulary: 

•  Fire  Support 

•  IEW 

•  ADA 

•  CSS 

•  Maneuver 

•  A2C2 

•  NBC 

•  MP 

•  Eng/Terrain 

•  CMO 

•  Weather 

•  Signal 

•  Enemy 


The  joint  future  will  require  redefining  our  basic  mission  applications.  Joint  Command  and 
Control  (JC2),  and  the  joint  mission  capability  packages  it  is  to  support,  will  be  replacing  the 
various  legacy  versions  of  Global  Command  and  Control  System  (GCCS).  From  a  Navy 
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perspective  where  is  antisubmarine  warfare  (ASW)  in  the  joint  mission  capability  packages?  In 
the  joint  world  there  is  no  ASW,  rather  ASW  must  be  seen  as  supporting  and  drawing  on  Force 
Protection,  Situational  Awareness,  Intelligence,  etc.  As  we  implement  JC2  we  need  a  C2-core 
“information  backplane”  that  spans  the  joint  set  of  mission  areas  and  is  rich  enough,  and  generic 
enough,  to  integrate  across  the  mission  areas.  The  C2IEDM  can  serve  as  the  C2-core  baseline 
and  the  information  backplane  in  the  next  generation  of  NCO/W  systems  and  services. 


To  showcase  multinational  consensus-based  standards,  OSD  (AS&C)  sponsored,  twelve 
demonstrations  of  MIP/C2IEDM  Col  capabilities  at  DISA  and  Joint  Forces  Command.  Canada, 
Portugal  and  the  United  States  Army  teams  were  brought  together  and  their  MIP-compliant 
national  systems  (used  also  at  the  MIP  IOT&E)  were  integrated  and  run  through  an 
operational/tactical  scenario.  The  two  maritime  sets  of  control  measures  (submarine  operating 
area  with  Tomahawk  Launch  Basket  and  route,  and  Carrier  Battle  Group  Screen)  and  tracks  were 
not  in  the  original  scenario.  They  were  quickly  and  easily  specified  using  the  Portuguese  ground 
tactical  system,  which  uses  C2IEDM  as  its  “information  backplane”.  The  C2IEDM  already  has 
generic  semantics  for  control  features  and  metadata,  e.g.,  associated  organization.  Once  entered 
this  information  was  immediately  exchangeable  with  the  C2IEDM  Col-complaint  Canadians  and 
U.S.  systems! 

Additional  notes - 

This  example  of  extensibility  and  interoperability,  based  on  C2IEDM,  shows  the  power  and 
efficiency  of  Col  consensus-based  concepts  and  semantics. These  views  of  SICCE  are  meant  to 
show  the  existing  Joint  nature  of  the  C2IEDM.  Using  the  Army-defined  control  measures  these 
typical  naval  control  measures  were  easily  represented  using  C2IEDM.  You  see  here  a: 

•naval  aircraft  carrier  battle  group  with  a  screen  formation 
•  submarine  operating  area  in  the  lower  left  corner 

•Tomahawk  land  attack  missile  launch  basket  (declared  appropriately  as  a  “weapons  firing  area” 
in  the  C2IEDM) 
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•starting  from  the  submarine  location  the  Tomahawk  flight  route  to  the  target 
•  defensive  naval  minefield  protecting  a  port. 

SICCE  can  show  the  situation  in  both  2D  and  3D  as  requested  by  the  operator. 

It  is  important  to  emphasis  that  what  is  shown  is  not  simply  a  graphic  but  rather  a  graphical 
representation  of  information  in  the  C2IEDM  data  base. 


This  is  Transformational 


•  The  C2IEDM  is  not  an  application,  or  agent 
technology,  or  web  service  (A/AT/WS)! 

■  It  is  a  view  of  the  foundational  knowledge 
required  to  make  A/AT/WS  Better! 

•  It  is  a  technical  foundation  enabling  transforming 
interoperability  from  point-to-point  to  Col-based. 

■  It  captures  the  warfighter  operational  consensus 
required  to  build  technical  solutions  that  are 
operationally,  semantically  and  referentially 
meaningful  and  complete. 

•  The  C2-core  Col  gives  us  a  path  to  Joint, 
Combined  and  Inter-agency  interoperability 


The  C2IEDM  is  not  an  application,  it  is  not  an  agent  technology,  and  it  is  not  a  web  service.  It 
does  however  capture  war  fighting  operational  consensus  and  the  foundational  domain 
knowledge  required  to  make  these  kinds  of  capabilities  better.  As  a  well-defined  and 
internationally  vetted  C2-core,  the  C2IEDM  gives  us  a  good  path  to  joint,  combine  and 
interagency  interoperability. 


IM/S/SEA 

tlAPftm  COTTERS 


NEWPORT 


Transformations 


•  Not  just  a  technical 
alternative 


Consensus-based 
semantic  alignment 


Not  technology  led 
Not  system  led 
Not  new  a  stovepipe 


Warfighter  led 

Mission  /  Col  led 

C2  cross-cutting/ 
integrated 


•  Don’t  start  over 


Leverage 


Better,  Faster,  Cheaper 
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This  move  to  semantic  alignment  must  be  warfighter  led.  The  foundational  operational  and 
technical  consensus  work  of  the  MIP,  resulting  in  the  C2IEDM,  can  accelerate  this  fundamental 
change.  It  creates  a  technical  foundation,  enabling  and  accelerating  the  type  of  transformational 
interoperability  we  seek.  It  moves  us  from  point-to-point  to  community-of-interest-based 
information  exchange  capability.  It  may  only  be  an  80%  solution  to  our  C2-core  operational  and 
tactical  exchange  requirements,  and  each  Col  will  need  to  extend  it  to  some  degree,  but  80%  is  a 
pretty  good  place  to  start.  In  this  new  paradigm,  our  goal  can  and  should  be  better,  faster,  and 
cheaper. 
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Overview 

The  idea  of  Net  Centric  Warfare  as  described  in  D.  Alberts  and  R.  Hayes  Command  and 
Control  Research  Program  (CCRP)  book  “Power  to  the  Edge”  focuses  on  organizational 
networks.  It  is  computer  nets  and  grids  that  enable  the  necessary  communications  and 
knowledge  exchange  being  the  technical  prerequisite  for  efficient  Net  Centric  Warfare. 
The  current  software  paradigm  to  cope  with  these  challenges  is  to  apply  services  within 
service-oriented  architectures  (SOA).  SOA  is  a  collection  of  composable  services.  A 
service  is  a  software  component  that  is  well  defined,  both  from  the  standpoint  of  software 
and  operational  functionality.  In  addition,  a  service  is  independent,  i.e.,  he  doesn't 
depend  on  the  context  or  state  of  any  application  that  calls  it.  Currently,  these  services 
are  typically  implemented  as  web  services.  Services  in  grids  are  often  referred  to  as  grid 
services.  Although  different  standards  may  be  used  for  the  implementation  of  the 
service,  web  services  and  grid  services  are  used  as  synonyms  in  this  paper.  The 
advantage  of  using  web  standards  in  an  SOA  is  that  the  services  can  more  easily  adapt  to 
utilize  distributed  applications  in  heterogeneous  infrastructures.  Nothing  in  particular  has 
to  be  done  programmatically  to  the  service,  except  to  enable  it  to  receive  requests  and 
transfer  results  using  web-based  messaging  and  transportation  standards.  In  many  cases, 
web  services  are  straightforward  and  existing  software  can  easily  be  adapted  to  create 
new  web  services  usable  within  an  SOA. 

The  use  of  Modeling  &  Simulation  (M&S)  applications  to  support  the  warfighter 
is  an  established  requirement.  However,  in  system-centric  environments  solutions  are 
likely  to  be  interface  driven  and  point-to-point  solutions  with  only  a  limited  potential  for 
reuse.  With  the  advent  of  SOA  and  their  application,  a  real  common  heterogeneous 
information  infrastructure  for  Net  Centric  Warfare  with  embedded  operational  M&S 
functionality  is  feasible. 

This  paper  will  motivate  the  use  of  operational  M&S  services  for  the  warfighter, 
will  introduce  the  common  concepts  of  services,  and  gives  examples  on  how  M&S 
services  can  be  integrated  into  future  grid-based  Command  and  Control  systems.  It  is  a 
white  paper  collecting  various  ideas  and  gives  references  to  papers  and  presentations  with 
the  necessary  academic  depth.  It  was  written  to  give  an  overview  and  refer  to  papers 
detailing  underlying  technical  challenges  and  solutions.  This  paper  summarizes  the  ideas 
of  the  papers  listed  in  the  reference  section. 
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Operational  Requirements 

The  operational  requirement  for  a  closer  integration  and  the  migration  towards  a  common 
information  infrastructure  are  rooted  in  the  ideas  of  Net  Centric  Warfare.  While  the  use 
of  simulation  to  support  the  warfighter  directly  and  indirectly  via  training  simulators  and 
simulation  systems,  the  use  of  simulation  within  procurement  and  acquisition,  training  for 
analysis  of  equipment,  organization,  and  doctrine,  experimentation  to  support  the 
transformation  of  the  armed  forces,  and  even  to  some  limited  degree  the  support  of  real 
operations  is  established,  the  idea  to  embed  operational  M&S  components  into  real 
command  and  control  systems  to  deliver  immediate  support  as  decision  support  tools  is 
still  quite  new. 

This  view  changed  with  the  advent  of  Net  Centric  Warfare.  Net  Centric 
Command  and  Control  operations  postulate  that  the  more  information  we  can  collect, 
create,  and  share  about  the  adversary,  the  operational  environment,  our  capabilities, 
readiness,  and  logistics,  the  more  we  can  focus  our  capabilities  to  produce  desired  effects 
with  less  risk  of  unintended  consequences  and  more  efficient  expenditure  of  national 
resources.  This  migration  to  an  information  sharing  and  dissemination  system  will  need 
to  include  both  a  hierarchical  (to  accommodate  military  Command  and  Control  doctrinal 
functions)  and  a  peer-to-peer  ability  to  share  and  access  information  and  functionality 
between  all  levels  in  the  Command  and  Control  system.  This  new  capability  is  required 
to  enable  sharing  of  unprocessed  or  uncorrelated  raw  data  with  selected  users  on  demand, 
and  allows  distributed  functionality  of  advanced  collaborative  planning,  coordination  and 
decision  support  applications.  Further,  with  this  advanced  information  flow  and 
accessibility,  intrinsic  Command  and  Control  applications  to  enable  "sense  making"  of 
information  overload  and  for  tailoring  a  Command  and  Control  node  to  a  specific 
purpose  or  role  become  apparent.  This  new  role  for  Net  Centric  Command  and  Control 
requires  applications  traditionally  found  in  the  M&S  community.  They  must  be 
integrated  into  Command  and  Control  and  will  perform  an  important  function  in  the 
enhanced  capabilities  of  the  Joint  Command  and  Control  (JC2)  system  of  the  future. 

In  order  to  discuss  and  measure  the  increase  in  efficiency,  the  Net  Centric 
Warfare  quality  value  chain  introduces  the  levels  of  data,  information,  knowledge,  and 
awareness  quality. 

•  The  value  chain  starts  with  Data  Quality  describing  the  information  within  the  underlying 
Command  and  Control  systems. 

•  Information  Quality  tracks  the  completeness,  correctness,  currency,  consistency,  and 
precision  of  the  data  items  and  information  statements  available. 

•  Knowledge  Quality  deals  with  procedural  knowledge  and  information  embedded  in  the 
Command  and  Control  system  such  as  templates  for  adversary  forces,  assumptions  about 
entities  such  as  ranges  and  weapons,  and  doctrinal  assumptions,  often  coded  as  rules. 

•  Finally,  Awareness  Quality  measures  the  degree  of  using  the  information  and  knowledge 
embedded  within  the  Command  and  Control  system.  Currently,  awareness  is  explicitly 
placed  in  the  cognitive  domain. 

Command  and  Control  needs  quality  support  on  all  levels.  The  underlying  assumption  is 
that  the  quality  of  Command  and  Control  itself  will  be  improved  by  an  order  of 
magnitude  when  a  new  level  of  quality  is  reached  in  this  value  chain.  This  can  be 
explained  as  follows: 
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•  Data  quality  is  characterized  by  stand-alone  developed  systems  exchanging  data  via  text 
messages,  such  as  the  U.S.  Message  Text  Format.  Standardized  data  exchange  ensured 
the  data  flow,  but  every  system  had  to  interpret  the  data  in  its  own  and  individual 
business  rules,  which  often  led  to  different  interpretation  of  the  same  data  in  different 
systems.  Until  recently,  this  was  the  best  information  technology  (IT)  could  do. 

•  The  federated  systems  using  the  Common  Operating  Picture  (COP)  resulted  in  an  order 
of  magnitude  improvement  of  the  Command  and  Control  quality.  Instead  of  common 
data,  the  staffs  share  common  information,  as  data  is  displayed  in  context.  The  COP 
enables  them  to  work  more  effectively  and  more  efficiently.  This  is  the  state  of  the  art  of 
IT  support.  The  Command  and  Control  Research  Program  (CCRP)  of  the  US  DoD 
supported  experiments  showing  that  the  COP  really  resulted  in  better  Command  and 
Control  decision  than  data  driven  solutions. 

•  The  next  step,  which  is  enabled  by  service-oriented  web-based  infrastructures  (but  not  yet 
operationally  used),  will  be  the  use  of  models  and  simulations  for  decision  support. 
Simulation  systems  are  the  prototype  for  procedural  knowledge,  which  is  the  basis  for 
knowledge  quality.  Simulation  systems  can  be  used  to  evaluate  alternative  courses  of 
actions,  to  deliver  orders  and  the  commander’s  intent.  One  of  the  main  challenges  of 
Command  and  Control  is  the  dynamic  and  agile  battle  management.  Dynamics  and 
agility  are  characteristics  of  simulation  systems,  or,  in  other  words,  dynamic  and  agile 
battle  management  results  in  the  application  of  M&S  functions  (whatever  they  are  called 
by  their  developers). 

•  Finally,  using  intelligent  software  agents  to  continually  observe  the  battle  sphere,  apply 
models  and  simulations  to  analyze  what  is  going  on,  to  monitor  the  execution  of  a  plan, 
and  to  do  all  the  tasks  necessary  to  make  the  decision  maker  aware  of  what  is  going  on, 
Command  and  Control  systems  can  even  support  situational  awareness,  the  level  in  the 
value  chain  traditionally  limited  to  pure  cognitive  methods.  With  the  application  of 
software  agents  and  the  availability  of  necessary  metadata,  future  SOA-based  JC2  system 
will  be  able  to  support  this  level  as  well. 


Figure  1:  Command  and  Control  Improvements  [7] 
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The  section  motivated  that  operational  M&S  services  are  needed  to  support  the 
warfighter  in  future  JC2  systems  like  envisioned  in  the  Global  Information  Grid  (GIG). 
The  following  sections  will  cope  with  the  technical  requirements  enabling  this. 

Why  do  we  need  a  Common  Language  in  the  GIG 

The  actual  trend  within  the  US  DoD  is  to  “let  the  community  evolve”  towards  standards. 
Mandating  of  standards  has  been  replaced  by  the  idea  to  use  metadata  standards  enabling 
the  mapping  of  information  elements  to  each  other  in  case  of  need  using  data  mediation 
services.  While  the  author  supports  the  idea  of  reducing  mandates  where  not  necessary,  a 
common  understanding  of  the  data  to  be  exchanged  is  the  fundament  for  interoperability. 
Although  not  sufficient,  data  interoperability  is  necessary  for  interoperability  on  higher 
levels,  as  depicted  in  figure  1.  Without  data  interoperability,  we  will  never  reach 
information  interoperability  within  the  supporting  IT  systems.  One  of  the  most  urgent 
problems  that  has  to  be  solved  before  M&S  services  in  service-oriented  architectures  can 
become  reality  is  meaningful  semantic  data  interoperability  for  information  exchange 
between  the  services.  While  the  Extensible  Mark-up  Language  (XML)  enables  good 
solutions,  XML  alone  is  not  sufficient.  To  cope  with  this  challenge,  the  US  DoD 
established  the  XML  Repository,  which  is  used  to  collect  all  relevant  XML  tag  sets  used 
within  the  responsibility  of  the  US  DoD.  In  addition  to  the  DoD  XML  Registry,  where 
XML  tag  sets  are  simply  registered,  the  U.S.  Department  of  Defense  established  the 
“DoD  Metadata  Registry  and  Clearinghouse.”  The  definition  of  the  DoD  Discovery 
Metadata  Specification  (DDMS)  is  a  very  important  step  towards  data-driven  net  centric 
interoperability.  The  actual  version  of  the  DDMS  provides  basic  summary  content 
elements  to  capture  content  metadata.  Activities  are  underway  to  test  additional 
summary  content  elements  that  provide  a  more  robust,  structured  method  of  describing 
the  contents  of  a  resource. 

The  real  potential  of  SOAs  lies  in  the  possibility  to  compose  services  and  to 
orchestrate  their  execution  enabling  new  functionality  compositions  to  fulfill  the  current 
often  changing  user  requests  “on  the  fly.”  To  this  end,  information  must  be  exchangeable 
between  all  composed  services.  In  order  to  do  this  in  a  meaningful  manner,  i.e.,  not 
simply  exchanging  bits  and  bytes  but  ensuring  the  interpretation  of  data  in  a  consistent 
way  leading  to  the  same  information,  knowledge,  and  ultimately  awareness  within  the 
services  and  their  users,  each  service  has  to  know  what  data  is  located  where,  the 
meaning  of  data  and  its  context,  and  into  what  format  the  data  have  to  be  transformed  to 
be  used  in  respective  services  composed  into  a  distributed  application  within  the  overall 
system.  To  generate  the  answers  to  these  questions  is  the  objective  of  data 
administration,  data  management,  data  alignment,  and  data  transformation,  which  can  be 
defined  as  the  building  blocks  of  a  new  role  in  the  interoperability  process:  Data 
Engineering. 

Data  engineering  is  already  a  tremendous  task  when  being  used  to  couple  two 
existing  systems.  The  challenge  becomes  greater  within  an  SOA.  The  developer  of  a 
service  does  not  know  who  is  going  to  use  his  service  in  the  future.  When  he  defines  the 
data  to  be  imported  into  his  services  and  the  data  produced  as  a  result,  he  cannot  assume 
how  this  data  will  be  used,  under  what  constraints,  etc.  It  is  therefore  necessary  to  avoid 
ambiguity.  A  common  language  is  necessary  to  be  used  as  a  reference  by  all 


178 


folk:  Operational  Modeling  &Simulation  Services 


participating  players,  including  services  and  software  agents.  It  is  important  to 
distinguish  between  the  role  of  the  reference  model  and  the  implemented  solution.  A 
common  language  does  not  imply  that  all  services  are  using  the  same  data  model  or  the 
same  implementation.  They  just  use  the  same  reference  model  to  unambiguously  define 
the  meaning  of  their  data. 

In  summary,  a  common  language  spoken  by  all  participants  is  required.  While 
the  mandate  for  a  common  implementation  is  not  recommended,  the  mandate  for  a 
common  reference  model  for  documentation  and  mediation  is  perceive  as  the  necessary 
requirement  for  efficient  and  interoperable  solutions  by  the  author.  The  view  is  not  a 
contradiction  to  but  easily  aligned  with  the  current  ideas  on  Net  Centric  Data 
Management.  The  only  difference  is  to  use  a  common  language  when  defining  the  mete 
data  constructs  used  in  DDMS  and  similar  constructs. 

C2IEDM  as  a  Common  Language  in  the  GIG 

This  leads  to  the  question,  which  language  should  be  spoken.  The  author  recommends  to 
use  the  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM).  To 
understand  this  recommendation,  a  short  overview  of  the  history  is  necessary. 

In  1978,  NATO’s  Long-Term  Defense  Plan  (LTDP)  Task  Force  on  C2 
recommended  that  an  analysis  be  undertaken  to  determine  if  the  future  tactical  Automatic 
Data  Processing  (ADP)  requirements  of  the  Nations  (including  that  of  interoperability) 
could  be  obtained  at  a  significantly  reduced  cost  when  compared  with  previous 
approaches.  In  early  1980,  the  then  Deputy  Supreme  Allied  Commander  Europe  initiated 
a  study  to  investigate  the  possibilities  of  implementing  the  Task  Force’s 
recommendations.  This  resulted  in  the  establishment  of  the  Army  Tactical  Command 
and  Control  Information  System  (ATCCIS)  Permanent  Working  Group  (APWG)  to  deal 
with  the  challenge  of  the  future  Command  and  Control  information  systems  of  NATO. 
The  ATCCIS  approach  was  designed  to  be  an  overall  concept  for  the  future  command 
and  control  systems  of  the  participating  nations.  One  constraint  was  that  each  nation 
could  still  build  independent  systems.  To  meet  this  requirement,  ATCCIS  defined  a 
common  kernel  to  facilitate  common  understanding  of  shared  information,  the  so-called 
Generic  Hub.  In  1999,  ATCCIS  became  a  NATO  standard  with  the  new  name  Land 
Command  and  Control  Information  Exchange  Data  Model  (LC2IEDM).  In  parallel  to 
this,  the  project  managers  of  the  Army  Command  and  Control  Information  Systems  of 
Canada,  France,  Germany,  Italy,  the  United  Kingdom,  and  the  United  States  of  America 
established  the  Multilateral  Interoperability  Program  (MIP)  in  April  1998.  By  2002,  the 
activities  of  LC2IEDM  and  MIP  were  very  close,  expertise  was  shared,  and  specifications 
and  technology  were  almost  common.  The  merger  of  ATCCIS  and  MIP  was  a  natural 
and  positive  step.  LC2IEDM  became  the  data  model  of  MIP.  Finally,  in  2003  the  name 
was  changed  to  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM). 

There  are  two  application  domains  for  the  C2IEDM  within  NATO:  Data 
Management  and  Information  Exchange.  The  NATO  Data  Administration  Group  used 
the  C2IEDM  to  map  all  information  exchange  requirements  between  the  national 
command  and  control  systems  to  it  in  order  to  ensure  semantic  (What  do  the  data  mean?) 
and  pragmatic  (What  are  the  data  used  for?)  interoperability  between  the  systems.  The 
MIP  data  managers  will  continue  this  task  after  the  merger  between  MIP  and  C2IEDM  is 
finished.  MIP  also  uses  the  C2IEDM  to  exchange  data  between  national  command  and 
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control  systems  in  order  to  foster  sharing  information  and  gain  a  common  understanding 
on  what  is  happening  on  the  battlefield.  To  this  end,  the  national  systems  establish  data 
translation  layers  mapping  their  internal  data  presentation  to  the  data  elements  of 
C2IEDM  for  information  exchange  with  the  other  systems.1 

Currently,  C2IEDM  comprises  data  elements  describing  a  common  vocabulary 
consisting  of  176  information  categories  that  include  over  1500  content  elements. 
C2IEDM  is  divided  into  a  Generic  Hub  comprising  the  core  of  the  data  identified  for 
exchange  across  multiple  functional  areas  and  special  functional  areas  extending  the 
Generic  Hub  under  national  responsibility  to  cope  with  information  exchange  needs  of 
national  concern.  C2IEDM  lays  down  a  common  approach  to  describe  the  information  to 
be  exchanged  and  is  not  limited  to  a  special  level  of  command,  force  category,  etc.  In 
general,  C2IEDM  describes  all  objects  of  interest  on  the  battlefield,  e.g.,  organizations, 
persons,  equipment,  facilities,  geographic  features,  weather  phenomena,  and  military 
control  measures  such  as  boundaries.  Besides  the  technical  maturity  of  this  data  model, 
the  recommendation  to  use  C2IEDM  as  the  reference  model  for  military  information 
exchange  is  driven  by  the  fact  that  all  participating  MIP  nations  already  agreed  that  the 
information  exchange  captured  in  C2IEDM  is  operationally  relevant  and  sufficient  for 
allied  operations.  In  other  words:  military  and  technical  experts  from  10  full  member 
nations  (Canada,  Denmark,  France,  Germany,  Italy,  The  Netherlands,  Norway,  Spain, 
The  United  Kingdom,  and  The  United  States)  as  well  as  14  associate  member  nations 
agreed  that  C2IEDM  is  an  adequate  and  operational  meaningful  way  to  exchange 
information  about  military  operations,  including  new  tasks  like  anti-terror  operations. 
Speaking  C2IEDM  means  speaking  in  operational  terms  to  14  nations  in  an  accepted 
manner  and  in  a  NATO  standard. 

XML  based  Data  Mediation  Services 

How  can  we  use  the  C2IEDM  as  a  common  reference  without  implementing  it?  How  can 
we  make  use  of  the  data  modeling  expertise  of  hundreds  of  man-years  without 
incorporating  the  model  into  the  services?  How  can  two  services  using  different  internal 
data  representations  be  coupled  and  exchange  information  unambiguously  without  having 
to  change  their  data  model? 

The  answer  to  these  questions  lies  within  “XML  Mediation  Services  utilizing 
Model  Based  Data  Management.”  In  general,  data  management  is  planning,  organizing 
and  managing  of  data  by  defining  and  using  rules,  methods,  tools  and  respective 
resources  to  identify,  clarify,  define  and  standardize  the  meaning  of  data  as  of  their 
relations.  This  can  be  done  individually  or  by  using  a  reference  data  model  to  which  all 
data  elements  are  mapped  to  unambiguously  define  their  meaning.  Following  the 
arguments  given  in  the  previous  section,  the  author  recommends  to  use  the  C2IEDM  as 
this  reference  model  for  military  services. 

In  the  GIG,  the  translation  of  data  formats  used  by  the  web  services  is  handled  by 
the  mediation  services,  which  belong  to  the  enterprise  wide  applicable  Net  Centric 
Enterprise  Services  (NCES).  Concerning  these  concept  documents,  mediation  services 
will  initially  focus  on  the  ability  to  transform  between  schema/document  formats 


As  the  mapping  is  done  under  national  responsibility,  the  solutions  may  not  be  aligned 
sufficiently.  XML  based  Data  Mediation  Services,  as  described  in  the  following  section,  are  the 
recommended  alternative  to  such  national  data  mapping  and  mediation  solutions. 
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represented  in  XML,  which  supports  the  use  of  services  discovered  via  the  Discovery 
Service.  Mediation  Services  will  make  use  of  service  registries  and  metadata  repositories 
to  facilitate  transformation  of  data  interchange  formats.  However,  it  is  not  specified  how 
this  mapping  will  be  organized  to  avoid  another  set  of  individual  point-to-point  mappings 
between  services  which  cannot  be  reused  by  alternative  solutions.  The  danger  is  that 
stove-piped  systems,  which  cannot  interact  due  to  misaligned  system  definitions,  are 
replaced  with  stove-piped  services  that,  although  running  within  a  technically  common 
infrastructure,  are  not  aligned  concerning  their  data  information  exchange  definitions. 
“XML  Mediation  Services  utilizing  Model  Based  Data  Management”  bridges  the  gaps  as 
follows: 

•  Every  service  defines  its  information  exchange  need  using  XML 

•  C2IEDM  can  be  modelled  using  XML  as  well2 

•  Data  management  for  XML  based  solutions  equals  tag  set  management 

•  Tag  set  management  results  in  function-supported  mapping  structures  from  one  tag  set  to 
the  other.3 

•  These  results  can  be  used  to  configure  the  mediation  services,  which  then  can  mutually 
translate  the  XML  dialects  into  each  other.  In  simple  cases,  this  can  be  done  using 
Extensible  Stylesheet  Language  Transformation  (XSLT). 

Alternatively,  each  service  can  use  its  own  mediation  wrapper  allowing  him  to  speak  and 
listen  to  C2IEDM  on  the  GIG,  but  to  use  his  efficient  and  application-specific  data  model 
internally.  It  should  be  pointed  out  that  the  data  management  and  alignment  work  must 
be  done  for  every  two  services  to  be  composed  anyhow,  the  recommendation  is  therefore 
to  use  common  (meta-)  standards  from  the  beginning. 

Summary 

Service-oriented  architectures  enabling  the  implementation  of  the  Global  Information 
Grid  are  evolving  rapidly.  Operational  M&S  services  should  be  part  of  the  architecture 
in  order  to  support  the  warfighter  with  dynamic  and  agile  services  within  all  simulation 
application  domains,  ranging  from  training  to  real  operations. 

In  order  to  make  better  use  of  the  services  delivering  the  necessary  functionality, 
intelligent  software  agents  are  required.  The  agents  need  to  make  sense  of  the  services 
functionality,  their  use  of  data,  and  their  behavior.  One  of  the  most  challenging  tasks  in 
this  context  is  the  management  of  information  exchange  requirements  of  services  in  a 
way  that  these  services  can  be  composed  and  orchestrated  with  other  services  during 
runtime  delivering  the  functionality  as  specified  by  users  during  the  ongoing  operation. 

The  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM)  is  a 
matured  approach  for  a  military  ontology  in  the  domain  of  Command  and  Control. 
C2IEDM  has  been  proven  to  be  flexible  enough  to  cope  with  all  information  exchange 
requirements  of  services.  Technically,  the  definition  of  mediation  layers  to  make  this 
information  available  to  services  in  general,  including  intelligent  software  agents,  is 


'  There  are  several  alternative  ways  to  derive  an  XML  model  from  the  C2IEDM  data  model.  We 

recommend  to  use  the  method  as  developed  by  the  Institute  for  Defense  Analysis  (IDA). 

This  assumes  that  the  tag  sets  belong  to  the  same  information  domains,  i.e.,  that  they  are  aligned, 
and  that  they  are  of  similar  resolution,  so  that  not  too  many  aggregation  functions  are  needed.  The 
functions  are  needed  to  support  simple  operations,  such  as  summing  and  subtracting.  The  ideal  case  is  that 
only  reversible  functions  are  used,  as  this  ensures  that  no  information  gets  lost  in  the  transformation. 
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feasible.  XML  can  be  used  as  a  syntax  layer,  the  C2IEDM  definitions  can  be  used  for 
ensuring  semantic  interoperability,  and  the  C2IEDM  structures  and  views  -  which  have 
been  agreed  to  by  military  operators  of  the  developing  nations  -  can  insure  that  the 
pragmatic  view,  i.e.  how  the  data  is  used  -  is  aligned  as  well.  The  results  can  be  captured 
using  XSLT  and  can  be  immediately  applied  for  mediation  service  configuration. 

By  utilizing  these  technologies,  military  IT  can  support  Joint  Command  and 
Control  not  only  on  the  data  and  information  level,  but  can  increase  knowledge  and 
maybe  even  situation  awareness. 
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What  Is  Battle 


XMSF 


Management  Language  (BML)? 


•  BML  is  the  unambiguous  language 
used  to: 

-  Command  and  control  forces  and 
equipment  conducting  military 
operations  and 

-  To  provide  for  situational  awareness  and 
a  shared,  common  operational  picture. 


Along  with  this  definition,  we  offer  four  principles  that  guide  our  discussion  of  BML  though  the 

paper: 

1)  BML  must  be  unambiguous; 

2)  BML  must  not  constrain  the  full  expression  of  a  commander’s  intent; 

3)  BML  must  use  the  existing  C4I  data  representations  when  possible;  and  BML  must  allow 
all  elements  to  communicate  information  pertaining  to  themselves,  their  mission  and  their 
environment  in  order  to  create  situational  awareness  and  a  shared,  common  operational 
picture 
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•  BML  must  be  unambiguous 

*  BML  must  not  constrain  the  full 
expression  of  a  commander’s  intent. 

*  BML  must  be  mapable  to  existing  C4ISR 
data  representations 

•  BML  must  allow  all  elements  to 
communicate  information  to  create 
shared  awareness 


Do  we  have  a  BML? 


■  Battle  Management  Language 
currently  exists. 


■  Soldiers  use  it  every  day  to  command 
and  control  live  forces. 


■  Vocabulary  defined  by  the  doctrinal 
manuals...  _ 


(such  as  the  Army’s 
FM  1-02  Operational  Terms) 

*  Associated  grammar  defined  in 
other  doctrinal  manuals  and  from 
years  of  use. 

•  Its  focus 


is  human  -to-  human 
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The  Problem  £|ii 

XMS  F 

■  Our  current  BML  is  a  loosely  knit  “language” 
tailored  to  interpersonal  communication. 

■  Its  vocabulary  is  found  in  doctrinal  manuals  , 
but  it  lacks  clearly  delineated  rules  governing  its 
use  (semantics  and  syntax). 

■  It  is  riddled  with  ambiguity  and  overlapping 
definitions. 

■  As  such,  it  is  incapable  of  transitioning  to  the 
full  range  of  automation  desired  by  the  DoD. 


The  Problem  (cont.) 


If  we  are  to  train  as  we  fight,  then  we  must 
be  able  to  communicate  command  and 


control  information  via  the  same  C4I 


devices  in  all  environments: 


*  Live  training  and  operations  (soldier  to  soldier). 

*  Simulation  training,  mission  rehearsal,  and  decision 
aids  with  the  C4I  devices  stimulating  and  being 
stimulated  by  simulations.  (Live,  Constructive,  Virtual 
simulation) 


As  emerging  and  future  simulations  are  developed  we  are  faced  with  three  options  in  meeting  the 
requirement  for  BML.  First,  we  can  continue  as  we  have  in  the  past  and  create  BMLs  that  are 
specific  to  each  simulation.  Second,  we  can  develop  a  BML  that  is  standard  within  the 
simulation  community  and  create  interpreters  between  it  and  the  C4I  systems.  Finally,  we  can 
develop  a  BML  that  is  standard  within  both  the  simulation  and  C4I  domains.  To  support  the 
“train  as  we  fight”  principle,  we  recommend  developing  a  BML  that  is  standard  within  both 
domains. 
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The  next  step  in  solving  the  problem  is  developing  a  concept  for  a  BML.  Figure  2  depicts  the 
current  state  of  disparate  information,  messages  and  languages. 

The  sources  of  BML  exist  in  the  defined  operational  messages,  the  doctrinal  manuals  that  define 
the  vocabulary  and  provide  insight  to  the  semantics  and  syntax  of  the  operational  language,  and 
the  data  base  that  contains  the  representation  of  the  mission  space.  The  past  BMLs  provide 
insight  into  ways  to  combine  these  sources  to  impose  structure  to  the  operational  language  and 
reducing  the  use  free  text. 
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Since  the  JCDB  contains  the  representation  of  the  mission  space  it  is  only  natural  to  build  the 
language  used  to  communicate  about  the  mission  space  into  the  same  representation.  This  can  be 
accomplished  by  ensuring  the  doctrinal  terms  and  relationships  that  define  the  syntax  and 
semantics  are  incorporated  into  existing  and/or  new  data  structures.  Once  this  is  accomplished 
communicating  that  information  can  be  accomplished  with  a  variety  of  means  including  data 
replication,  XML,  existing  message  formats,  etc. 

Linking  the  doctrinal  base  into  the  JCDB  ensures  that  there  is  a  clear  mapping  to  support  XML 
and  other  techniques  and  it  also  ensures  that,  as  doctrine  evolves  to  meet  future  challenges,  the 
language  remains  current. 
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ce  of  Order  Resides  in  the  5  Ws 


vo  Company' Attack' hill  123  at  0630  hours 'to  secure 
an  over-watch  position 


The  5  Ws 

WHO:  which  unit  is  to  accomplish  the  task. 

-  Normally  identified  by  a  Unit  ID. 

-  When  Unit  ID  is  in  doubt,  could  be  identified  by  location. 

-  Could  be  identified  by  ROLE  (Main  Effort,  etc.) 


2.  WHAT:  the  task  to  be  accomplished. 

-  Could  be  either  an  operation  or  ARTEP  task. 

•  Selection  maybe  dependent  on  how  much  the  higher  commander 
wants  to  limit  his  subordinate.  The  more  specific  the  task  the 
less  it  conforms  to  “mission  type”. 


HOW:  In  mission  type  orders, 
how  to  do  a  task  is  left  up  to 
the  subordinate.  The  “general” 
how  for  the  order  itself  is  found 
in  the  context  of  the 
Commander’s  Intent  and  the 
Concept  of  Operations. 


3.  WHERE:  the  location  for  accomplishing 
the  task. 

•  Lat Long,  UTM,  MGRS,  etc. 

-Terrain  Feature  ID, 

Graphic  Control  Measure  ID 


4.  WHEN:  the  timing  of  the  task. 

-  Control  type  (AT  a  certain  time,  NLT  a  certain  time, 
EVENT  PLUS  T  (D+1,  H+2,  etc.) 

-  Parameters:  (DTG,  Event,  Time,  Unit  ID,  etc..) 


5.  WHY:  the  reason  for  accomplishing  the  task. 

-  Purpose  term.  (Attrit,  Defeat,  Destroy,  Contain,  Clear,  etc..) 

-  Parameters:  (dependent  on  the  term  but  required  for  clarificatioi 
Destroy  what?  Enemy  Force,  Terrain  Feature) 


Course  of  Action  Analysis  Example 


Graphics  convert  to  BML  "v-'X  (  3 

mg.  A 

Division  Mission  X./VASF 

Division  attacks  on  order  in  zone  to  seize  OBJ  SLAM. 

Division  Concept  of  Operations 

Form  of  maneuver:  Penetration 
Main  effort:  BLUE-MECH-BDE2, 

on  order  BLUE-ARMOR-BDE 1 
Supporting  effort:  BLUE-MECH-BDE 1 
BLUE-ARMOR-BN 1 

Deep:  None 

Reserve:  BLUE-AVN-BDE 1 
Security:  BLUE-CAV-SQN1 
Tactical  Combat  Force:  BLUE-MECH-TM1 


Tasks  to  Subordinates 


•Who 

•Wiat 

•When 

•Wiere 

•VWiy 

•BLUE-MECH-BDE1 

•Attacks 

•On  order 

•Zone 

•Fix  (MRR1 ) 

•BLUE-MECH-BDE2 

•Attacks 

•On  order 

•Zone 

•Penetrate  (MRR2) 

•BLUE-ARMOR-BDE1 

•Folows  and  Assumes  (B-M- 
BDE2) 

•On  order 

•Zone 

•Seize  (OBJ  SLAM) 

•BLUE-AVN-BDE 

•Occupy 

•On  order 

•AA  EAGLE 

•Reserve 

•BLUE-ARMOR-BN1 

•Folowand  Support  (B-A- 
BDE1) 

•On  order 

•2d  ne 

•Support  (B-A-BDE1) 

•BLUE-CAV-SQN1 

•Screen 

•On  order 

•Zone  (PL  AMBER  to  PL 
BLUE) 

•Protect  (Division  left  flank) 

•BLUE-MECH-TM1 

•Tactical  Combat  Force 

•On  order 

•DSA 

•Protect  (Division  Ftear  Area) 

This  slide  shows  an  example  of  a  COA  sketch.  Imagine  the  graphics  being  linked  to  the  BML. 
1)  we  can  interpret  the  overall  division  mission:  “Division  attacks  on  order  in  zone  to  seize  OBJ 
SLAM”  Note  that  in  place  of  the  general  description  of  Division  we  could  actually  identify  the 
specific  division  by  knowing  what  machine  we  were  logged  onto  and  keying  to  the  ORG  ID. 
Also  “on  order”  was  selected  as  the  when  for  this  example  since  there  is  not  enough  information 
to  determine  otherwise.  Normally  the  COA  sketch  would  be  accompanied  by  additional  products 
such  as  the  COA  statement  and  if  analysis  is  complete,  a  synchronization  matrix.  2)  we  can 
determine  the  Division’s  concept  of  operation.  Since  this  is  an  offensive  operation  we  are 
interested  in  the  chosen  scheme  of  maneuver,  in  this  case  a  penetration.  We  can  identify  the  main 
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and  supporting  efforts  as  indicated.  As  well  as  the  reserve,  security  and  tactical  combat  force. 
Again  without  the  additional  products  it  is  assumed  that  the  Aviation  Brigade  is  the  reserve.  It  is 
also  assumed  that  the  Cavalry  Squadron  is  performing  a  screen.  The  graphics  shows  it  doing  a 
security  mission  -  by  adding  an  S,  a  G,  or  a  C  to  the  graphic  this  would  be  clarified.  3)  we  can 
translate  the  graphics  into  specific  tasks  to  subordinates  as  shown.  This  could  all  be  linked  to  the 
proper  paragraphs  of  the  OPORD  and  completed  through  auto-fill. 

Though  the  simulation  may  only  be  able  to  interpret  the  message,  we  can  see  that  it  would  be 
fairly  easy  to  include  graphics  into  the  BML  and  translate  the  graphics  to  populate  the  correct 
fields  of  a  BML  message. 
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Core  Data  Model 

Command  &  Control 
Information  Exchange  Data 
Model  (C2IEDM) 
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BML  Developments 


*  Simulation  Interoperability  Standards 

Organization  (SISO)  Coalition  BML  Initiative 

-  United  Kingdom 

-  France 

-  Germany 

-  Strong  Interest  from  other  nations 


•  Other  Services 

-  Currently  developing  Air  Tasking  Order  in  BML 

-  Working  with  JFCOM  to  demonstrate  BML  in  large 
scale  exercise 
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Abstract:  This  paper  explores  the  use  of  decision  support  systems  in  the  nontraditional  role  of 
analyzing  architectures.  We  envision  a  scenario  in  which  an  analyst  will  need  help  determining 
the  relationship  between  two  portions  of  an  architecture,  and  show  how  a  decision  support 
system  might  provide  that  help.  The  decision  support  system  uses  an  ontology  that  is  derived 
from  the  Core  Architecture  Data  Model  (CADM).  We  show  how  we  derived  the  ontology  from 
that  model,  then  discuss  how  decision  support  can  be  embedded  in  the  ontology  and  utilized  by  a 
tool.  We  present  a  detailed  example  to  explain  our  work. 

1  Introduction 

This  paper  presents  follow-on  work  to  a  paper  given  at  the  2003  ONR/CADR  Decision  Support 
Workshop.  That  paper  explored  the  use  of  ontology-based  applications  for  automating  decision 
support,  with  a  special  emphasis  on  command  and  control  (C2)  systems  [IDA  2003].  The  C2 
emphasis  reflected  the  data  model  underlying  the  ontology:  the  Generic  Hub,  version  5  (GH5) 
[NATO  2000].  This  year’s  work  continues  to  study  the  role  of  ontologies  and  knowledge  bases 
in  decision  support,  but  uses  architectural,  rather  than  C2,  data  elements. 

Decision  support  for  C2  is  of  course  a  longstanding  problem  with  a  rich  history,  much  of  which 
predates  computers.  Architectures  are,  relatively  speaking,  a  recent  invention.  Architectural 
standards  are  not  so  well  evolved  as  C2  standards.  Then  too,  architecture  is  a  much  larger 
domain  than  C2  (which  is  saying  something).  A  C2  data  set  focuses  on  a  particular  operation, 
even  if  that  operation  happens  to  span  an  entire  theatre  of  war.  Architecture  allows  of  all  the 
concerns  that  go  into  the  planning,  procurement,  and  maintenance  of  a  system,  a  family  of 
systems,  or  a  system  of  systems.  Many  subsidiary  but  important  relationships  exist  among 
architectural  data  elements,  adding  further  complexity  to  an  architectural  data  model.  Decision 
support  for  architectures,  then,  is  more  intricate  and  multifaceted  than  for  C2.  Concrete  proof  of 
this  claim  can  be  provided  by  noting  the  number  of  data  elements  in  the  data  models  we  have 
studied:  833  in  the  C2  model,  4,128  in  the  architectural  model. 

This  year’s  work  also  had  technical  concerns  distinct  from  the  underlying  data  model.  The  rule- 
based  prototype  system  developed  in  2003  implemented  many  of  its  rules  as  Java  code.  This 
approach,  while  acceptable  in  a  prototype,  has  disadvantages  in  production  systems.  It  forces 
analysts  to  express  rules  in  a  non-natural  language:  in  a  programming  language,  rather  than  in  a 
domain-specific  form.  It  makes  certain  changes  (adding  new  rules,  evolving  existing  rules) 
difficult,  because  implementing  these  changes  requires  extra  programming,  realignment  of  the 
user  interfaces,  new  packaging,  and  configuration  management  of  the  deployed  versions.  A 
better  approach  is  to  implement  the  rules  directly  in  the  ontology,  and  preferably  in  a  language 
designed  specifically  for  that  purpose.  Rules  are  then  easier  to  develop  and  modify,  and  are  also 
centralized;  packaging  and  distribution  concerns  are  reduced.  However,  as  we  began  our  work 
the  feasibility  of  developing  realistic  rule  sets  for  the  architecture  domain  was  unknown,  and  so  a 
goal  of  this  year’s  project  was  primarily  to  determine  feasibility. 
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This  paper  presents  the  results  of  this  year’s  work  on  ontology-based  decision  support  for 
architectures.  Section  2  discusses  the  architecture  data  model  used.  Section  3  shows  how  this 
data  model  was  converted  to  an  ontology.  Section  4  covers  the  automated  decision  support  tools 
that  make  use  of  the  ontology.  Section  5  presents  conclusions  and  directions. 

2  The  Core  Architecture  Data  Model 

The  architecture  data  model  chosen  is  the  Core  Architecture  Data  Model  (CADM)  [OSD  2003]. 
The  CADM  is  designed  to  provide  a  common  approach  for  organizing  and  portraying  the 
structure  of  architecture  information.  Its  data  requirements  are  drawn  from  the  2,198  data 
requirements  in  the  DoD  Architecture  Framework  (DoDAF),  version  1.0  [DoDAF  2003].  The 
CADM  supports  all  of  these  requirements. 

The  CADM  was  primarily  designed  to  be  a  logical  rather  than  a  physical  data  model.  Its  purpose 
is  to  define  how  architecture  data  is  to  be  organized  and  related,  not  how  it  is  to  be  stored.  This 
said,  however,  the  reader  should  be  aware  that  physical  schemas  directly  derived  from  the 
CADM  logical  specifications  also  exist,  and  that  operational  architecture  data  repositories  have 
been  built  therewith. 

Figure  1  shows  an  overview  of  the  DoD  Architecture  Framework  (DoDAF).  It  comprises  three 
architectural  views:  operational,  system,  and  technical.  Each  of  these  views  is  devoted  to 
presenting,  in  graphical  or  textual  form,  selected  facets  of  an  architecture: 

•  The  Operational  View  identifies  those  products  that  define  participants,  participant 
relationships,  and  participant  information  needs. 
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High-level  Operational  Concept  Diagram 
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Figure  1.  Overview  of  Selected  DoDAF  Architecture  Products 
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•  The  System  View  shows  how  a  set  of  one  or  more  systems  interact  in  support  of  DoD 
requirements  identified  in  the  Operational  View. 

•  The  Technical  View  specifies  standards  and  conventions  to  which  systems  conform.  These 
standards  and  conventions  may  derive  from  the  Operational  View,  or  they  may  be  drawn 
from  the  System  View  when  systems  implement  standards  not  otherwise  prescribed. 

Each  view  comprises  multiple  sub- views.  For  example,  Figure  1  highlights  five  sub-views  of  the 
Operational  domain.  Each  DoDAF  architecture  domain  consists  of  some  set  of  interrelated 
architecture  products,  and  its  products  are  related  to  other  sub-views  both  as  in  and  out  of  the 
overall  Operational  domain  view. 

The  Operational,  System  and  Technical  views  comprise  the  set  of  all  possible  architecture 
products  that  comprise  any  given  DoDAF-conformant  architecture.  The  topmost  architecture 
product  of  the  Operational  View,  OV-1,  is  a  high-level  operational  concept  diagram.  Many 
architectural  products,  especially  top-level  ones,  are  diagrammatic  and  pictorial  representations 
of  information.  The  CADM  establishes  the  data  elements  needed  to  make  up  such  diagrams.  For 
example,  Figure  2  shows  the  key  entities  that  make  up  a  high-level  operational  concept  diagram, 
and  the  relationships  of  these  entities  to  other  critical  entities  in  the  Operational  View.  Note  that 
the  “central”  entity,  CONCEPT-GRAPHIC  {OV-1},  is  a  subtype  of  DOCUMENT.  Many  CADM  products  are 
ultimately  represented  as  “documents”,  in  the  general  sense  of  the  word.  A  document,  in  turn, 
has  multiple  associations,  both  with  other  documents  as  well  as  with  the  CADM  entities  that 
describe  its  contents. 

•  In  CADM  the  relation  of  a  given  document  to  other  documents  is  generally  accomplished  via 
DOCUMENT-ASSOCIATION,  which  defines  relationships  both  within  and  without  a  DoDAF 
product.  Figure  2  shows  those  associations  for  the  OV-1  product  within  the  Operational 
View. 

•  The  relation  of  DOCUMENT  to  the  MISSION  entity  in  OV-1  (see  Figure  2),  provides  context  for 
how  DoD  requirements  for  a  mission  might  be  satisfied. 

•  The  relation  of  DOCUMENT  to  the  SYSTEM  entity  in  OV-1  (in  a  many-to-many  relationship  via 
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SYSTEM-DOCUMENT),  describes  the  systems  that  play  a  role  in  a  given  high-level  operational 
view.  These  systems  can  be  either  actual  systems  or,  for  a  planned  architecture,  system 
candidates. 

3  Deriving  an  Ontology  from  the  CADM 

The  CADM  is  a  logical  data  model  written  in  the  IDEF1X  notation.  It  consists  of  entities, 
attributes,  and  relationships. 

An  ontology,  by  contract,  includes  a  catalog  of  terms  used  in  a  domain,  the  rules  governing  how 
those  terms  can  be  combined  to  make  valid  statements  about  situations  in  that  domain,  and  the 
"sanctioned  inferences"  that  can  be  made  when  such  statements  are  used  in  that  domain.  It  is, 
therefore,  designed  with  goals  other  than  data  storage  in  mind.  The  application  of  an  ontology  to 
decision  support  implies  that  an  ontology-derived  knowledge  base  must  be  more  than  an  entity- 
attribute-relationship  (ERA)  model:  it  must  support  reasoning  via  rules  about  a  data  set. 

There  is,  however,  a  great  advantage  in  leveraging  a  pre-existing  data  model  when  developing  an 
ontology,  because  any  such  data  model  is  likely  to  contain  valuable  descriptions  of  the  terms 
needed  to  describe  the  ontology  domain.  In  addition,  the  population  of  a  knowledge  base  is 
greatly  facilitated  if  the  catalog  of  terms  used  in  the  ontology  closely  track  those  of  an 
implemented  data  store  built  in  accordance  with  a  data  model. 

It  is  for  these  reasons  that  the  ontology  developed  for  this  project  is  based  on  the  underlying 
CADM  concepts.  The  ontology,  however,  extends  them  in  multiple  ways.  This  section  describes 
the  architecture  ontology  we  built  in  this  study  and  the  design  decisions  that  went  into  it. 

3.1  The  Architecture  Ontology  Model 

The  architecture  ontology  was  built  using  the  Protege  knowledge  base  editor  [Protege].  This  tool 
supports  an  OKBC  [OKBC  1998]  view  of  information,  based  on  a  class  hierarchy.  Each  class 
has  a  set  of  template  slots.  A  class  can  be  instantiated;  the  resulting  instance  has  an  own  slot 
based  on  each  template  slot.  These  own  slots  hold  information  about  the  instance.  The  nature  of 
this  information  is  determined  by  facets  associated  with  template  slots. 

Classes  and  slots  correspond  roughly  to  entities  and  relationships  in  an  ER  model.  Since  an  ERA 
model  is  a  special  case  of  an  ER  model,  the  OKBC  model  is  at  least  as  powerful  as  the  ER 
model.  In  fact  it  is  significantly  more  so. 

3.2  Mapping  CADM  Entities  and  Attributes  to  the  Ontology 

The  fact  that  data  model  entities  and  attributes  roughly  map  to  classes  and  template  slots 
suggests  a  straightforward  translation  of  the  CADM  from  a  logical  model  into  an  ontology.  We 
therefore  adopted  the  following  principles: 

•  Model  each  CADM  entity  as  a  class,  and  model  subtypes  as  subclasses. 

•  Model  each  CADM  attribute  as  a  template  slot. 

Accordingly,  the  CADM  ontology  contains  a  class  named  DOCUMENT.  This  class  has  a  template 
slot  corresponding  to  each  attribute  in  the  CADM  DOCUMENT  entity. 

This  basic  translation  scheme  works  quite  well  with  a  few  extensions.  Protege  includes  facets 
that  can  model  the  attribute  specification  elements  of  ERA  standards  such  as  IDEF1X 
[NIST  1993],  including  data  type,  minimum  and  maximum  values,  and  default  value.  Protege’s 
predefined  data  types  are  not  as  rich  as  those  in  SQL  definitions  [ISO  2003]  (and  ERA  models 
tend  to  use  SQL  definitions,  given  the  expectation  that  a  model  will  ultimately  be  represented  as 
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DOCUMENT 


Figure  3.  Two  CADM  Entities  and  their  Attributes 

a  database  scheme);  for  example,  a  Protege  template  slot  can  be  specified  as  floating-point  but 
not  with  precisions,  such  as  NUMBER(9,7)  (9  digits  total,  7  after  the  decimal  point,  well  suited  to 
representing  latitudes  with  precision  down  to  one  meter,  but  not  for  longitudes).  However,  the 
CADM-derived  architecture  ontology  uses  other  Protege  features  to  model  these  facets  of  data 
types. 

A  one-to-many  relationship  in  an  ERA  model  is  implemented  using  an  attribute  in  the  entity  of 
which  there  can  be  many  instances.  In  the  ontology,  the  child  class  corresponding  to  that  entity 
has  a  template  slot  that  models  the  relationship.  Automated  reasoning  applications  usually 
require  relationship  information  in  the  parent  class  as  well.  Protege  includes  several  OKBC 
concepts  that  support  parent- to-child  relationships: 

•  A  slot’s  range  can  be  an  instance  of  a  class. 

•  A  slot  can  have  multiple  values;  that  is,  its  value  can  be  a  set. 

•  A  slot  can  have  an  inverse  slot.  A  change  to  one  automatically  changes  the  other. 

The  CADM  entities  and  attributes  shown  in  Figure  3  are,  therefore,  translated  into  the  following 
classes  and  template  slots  in  the  ontology: 

•  Two  classes  DOCUMENT  and  DOCUMENT-ASSOCIATION. 

•  Template  slots  DOCUMENT  ABBREVIATED  NAME,  DOCUMENT  APPROVAL  CALENDAR  DATE,  DOCUMENT 
CATEGORY  CODE,  etc.  that  represent  values  of  organic  attributes  of  the  CADM  entity  DOCUMENT, 
and  template  slots  DOCUMENT-ASSOCIATION  BEGIN  CALENDAR  DATE-TIME,  DOCUMENT-ASSOCIATION  END 
CALENDAR  DATE-TIME,  and  DOCUMENT-ASSOCIATION  REASON  CODE  that  represent  organic  attributes 
of  the  CADM  entity  DOCUMENT-ASSOCATION.  The  logical  names  of  the  CADM  attributes  are 
used  as  names  of  template  slots.  The  naming  conventions  used  in  CADM  for  entity  attributes 
prefix  each  attribute  with  the  name  of  their  containing  entity.  We  follow  the  same  convention 
in  our  ontology,  which  has  the  added  advantage  of  making  all  corresponding  ontology  slot 
names  unique. 

•  Template  slots  DOCUMENT-is  ordinate  to-DOCUMENT-ASSOCiATiON  and  DOCUMENT-is  subordinate  to- 
DOCUMENT-ASSOCIATION;  these  are  associated  with  class  DOCUMENT. 

•  Template  slots  inv-DOCUMENT-is  ordinate  tO-DOCUMENT-ASSOCIATION  and  inv-DOCUMENT-is 
subordinate  tO-DOCUMENT-ASSOCIATION;  these  are  associated  with  class  DOCUMENT-ASSOCIATION 
and  are  inverse  slots  of  the  respective  slots  of  DOCUMENT. 

For  our  architecture  ontology  the  CADM  attributes  that  are  part  of  keys  and  are  not  also  foreign 
keys  are  not  translated.  In  a  knowledge  base,  every  frame  is  automatically  assigned  a  unique 
identifier  when  it  is  created.  This  identifier  assumes  the  role  of  a  key. 
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Figure  5.  Slot  Metaclasses  in  CADM 
Ontology 


CADM  foreign  key  attributes  are  translated  into 
template  slots  in  the  architecture  ontology,  but  with 
names  that  reflect  the  relationship  in  which  they 
participate  rather  than  the  name  of  the  attribute  from 
which  they  derive.  Thus  Ordinate  DOCUMENT  IDENTIFIER 
exists  in  the  ontology  as  inv-DOCUMENT-is  ordinate  to- 
DOCUMENT-ASSOCIATION.  CADM  complete  subtype 
discriminator  attributes  are  also  unnecessary  in  the 
architecture  ontology,  as  a  subclass  contains  enough 
information  to  identify  its  parent. 

3.3  Implementing  Slot  Semantics  Using 
Metaclasses 

The  characteristics  of  the  CADM  that  cannot  be  directly 
represented  in  Protege  can  be  implemented  through 
metaclasses.  A  metaclass  is  a  class  that  specifies 
semantics  of  classes,  slots,  and  facets  in  the  ontology. 
Protege  includes  a  special  class  :SYSTEM-CLASS  that  is  the 
superclass  of  metaclasses.  Protege  includes  a  standard 
set  of  metaclasses,  shown  in  Figure  4.  Ontology 
designers  may  add  semantics  to  classes,  slots,  and  facets 
by  modifying  or  extending  these  metaclasses. 

To  represent  CADM  data  types  with  more  detail  than 
Protege  normally  allows,  the  CADM  ontology  extends 
the  :STANDARD-SLOT  metaclass  with  seven  subclasses 
(Figure  5).  These  subclasses  are  based  on  the  data  type 
categories  in  the  CADM.  Each  subclass  has  template 
slots  that  provide  additional  detail.  For  example,  String- 


Slot  has  template  slots  String-Slot-Fixed-Length  (a  Boolean)  and  String-Slot-Maximum-Length  (a 
positive  integer).  All  string-valued  CADM  attributes  are  represented  in  the  CADM-derived 
architecture  ontology  as  slots  whose  value  type  facet  is  string,  but  whose  “type”  -  i.e.,  metaclass 
-  is  String-Slot.  Length  information  in  the  CADM  can  therefore  be  associated  with  the  slot. 


Metaslots  DateTime-Slot,  Date-Slot,  and  Money-Slot  do  not  add  any  template  slots  to  :STANDARD- 
SLOT.  They  exist  only  to  help  characterize  a  slot’s  role.  This  design  decision  is  arguably 
redundant,  because  CADM  attribute  names  include  a  description  in  their  name  (e.g.,  DOCUMENT 
PUBLICATION  CALENDAR  DATE,  DOCUMENT  ASSOCIATION  BEGIN  CALENDAR  DATE-TIME).  Our  decision  to 
allow  this  redundancy  in  the  architecture  ontology,  however,  was  made  for  two  reasons:  first,  to 
enforce  a  rule  that  all  organic  CADM  attributes  were  translated  to  well-defined  data  types;  and 
second,  in  anticipation  of  extensions  that  might  facilitate  reasoning. 


Slots  translated  from  code-valued  attributes  (those  whose  values  are  drawn  from  a  fixed  set  of 
prespecified  symbols)  require  special  treatment.  Protege  supports  symbolic  domains  as  a  value 
type,  and  the  CADM-derived  architecture  ontology  does  in  fact  use  that  feature  to  represent 
code-valued  slots.  However,  at  first  glance  the  codes  by  themselves  do  not  reflect  sufficient 
semantic  content  to  support  reasoning.  The  majority  are  integer  codes  with  no  inherent  relation 
to  their  domain,  and  the  string  values  are  often  one-  or  two-character  abbreviations.  What 
semantics  can  be  derived  from  a  code  is  found  in  the  code’s  textual  description. 
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The  CADM-derived  architecture  ontology,  therefore,  incorporates  code  descriptions.  The 
metaslot  Enumerated-Slot  includes  a  template  slot  Slot-Enumeration-Class.  The  value  type  of  this 
slot,  which  is  required,  is  a  subclass  of  class  Enumeration-Class.  Enumeration-Class  in  turn  has  two 
abstract  subclasses  that  are  used  to  group  the  two  kinds  of  enumerations  in  the  CADM:  strings 
and  integers.  Each  subclass  of  these  two  classes  models  the  set  of  codes:  both  code  values  and 
descriptions.  Thus  the  symbolic  value  associated  with  the  slot  can  be  mapped  to  an  instance  of 
some  Enumeration-Class  subclass.  Given  this  mapping,  the  textual  description  of  a  code  is 
available  for  reasoning. 

3.4  Representing  Views 

DoDAF  users  don’t  analyze  every  data  element  in  the  CADM.  They  concentrate  on  those 
elements  necessary  for  the  task  at  hand.  The  CADM  has  over  two  hundred  views  that  assist  in 
selecting  elements  relevant  to  areas  such  as  requirements,  operation,  system  analysis,  user  needs, 
and  procurement. 

The  CADM  ontology  recognizes  the  importance  of  views  and  represents  them  using  the  six-class 
structure  shown  in  Figure  6.  A  view  is  defined  as  an  instance  of  class  View.  This  class  has  three 
template  slots: 

•  A  string-valued  slot  defining  the  view’s  name. 

•  A  multi-valued  slot  named  view-classes,  consisting  of  instances  of  View-Class;  this  (indirectly) 
defines  the  classes  in  the  view. 

•  A  single-valued  slot  that  is  one  of  the  instances  of  the  view-classes  slot;  this  slot  defines  the 
“focus”  class  of  the  view.  A  view  has  a  single  class  that  can  be  identified  as  being  central  to 
the  view,  and  that  class  is  the  value  of  this  slot. 

The  View-Class  class  contains  template  slots  that  provide  information  about  a  specific  class  in  the 
view,  namely: 

•  A  class  that  is  one  of  those  translated  from  an  entity  in  the  CADM.  In  the  CADM-derived 
architecture  ontology,  these  classes  are  all  subclasses  of  CADM-Entity. 

•  Instances  of  View-Class-Association  that  denote  parent-to-child  (one-to-many)  relationships  of 
the  referenced  class. 

•  Instances  of  View-Class-Association  that  denote  child-to-parent  (many-to-one)  relationships  of 
the  referenced  class. 

•  The  template  slot  of  the  reference  class  that  provides  a  useful  identifying  string  when 
displaying  an  instance  of  the  class  to  a  user. 


©  :THINGa 
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•  Information  on  how  to  find  instances  of  other  classes  in 


©View 
©View-Class 
©View-Class-Association 
©View-Class-Path 
-©  Cls-lnsts-Path 
*-©  View-Regeneration-Path 


the  view  that  derive  from  a  given  instance  of  the 
referenced  class.  This  information  is  modeled  as  an 
instance  of  View-Class-Path;  it  is  discussed  in  Section  4. 


Figure  6.  CADM  Ontology 
Classes  Supporting  Views 


Class  View-Class-Association  models  associations  that  exist 
between  classes  in  the  view.  The  aggregate  set  of  associations 
can  also  be  derived  directly  through  examination  of  CADM 
entities.  However,  simply  knowing  the  set  does  not  provide 
enough  context  to  discern  certain  association  semantics.  For 
example,  class  DOCUMENT  has  ordinate  and  subordinate 
associations  with  document-association,  (see  Figure  3).  As 
another  example,  consider  ORGANIZATION  and  ORGANIZATION- 
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HOLDING-MATERIAL-ITEM  (see  Figure  7).  How  should  an  inference  engine  distinguish  between  the 
two  relationships  between  them:  when  is  it  appropriate  to  use  is  inventoried  by  and  when  is  it 
appropriate  to  use  provides?  In  our  architecture  ontology  the  View-Class-Association  identifies  one 
as  the  identifying  relationship. 


Figure  7.  A  CADM  Entity  with  Multiple  Parent-Child  Relationships 


4  Using  the  CADM  Ontology  in  Decision  Support 

This  section  discusses  how  a  decision  support  tool  can  use  the  CADM-derived  architecture 
ontology.  For  our  analysis  we  postulated  that  one  of  the  purposes  of  a  decision  support  tool 
would  be  to  assist  architecture  developers  in  evaluating  design  decisions.  Based  on  that 
assumption  we  have  developed  a  prototype  tool  that  enables  the  comparison  of  one  architecture 
view  to  another.  That  is,  given  a  populated  CADM  knowledge  base,  the  prototype  can  be  used  to 
rank  the  degree  to  which  instances  in  one  view  match  instances  in  another  view.  An  analyst 
could  use  the  architecture  ADS  tool  to  help  decide  how  well  DoDAF  architecture  products  of 
one  type  support  the  requirements  of  some  other  kind  of  architecture  product. 

More  concretely,  suppose  an  architect  is  analyzing  requirements  from  an  Operational  View.  For 
our  scenario,  let's  assume  that  these  requirements  are  specifically  from  an  OV-5,  which  deals 
with  activity  model  specifications.  The  architect  wants  to  know  what  systems  are  available  to 
help  satisfy  activity  model  requirements,  and  would  also  like  help  ordering  the  systems  in  terms 
of  suitability  to  the  activity  model  requirements  at  hand.  Let's  assume  that  this  information  is 
present  in  the  DoDAF  product  SV-1  for  that  architecture. 

Analysis  of  the  CADM  shows  that  there  are  relationships  between  activity  models  and  systems. 
Given  our  approach  in  building  the  architecture  ontology,  similar  relationships  also  exist  in  the 
prototype  architecture  ADS.  In  this  scenario,  we  assume  that  these  relationships  have  not  yet 
been  populated.  Activity  model  needs  have  been  described,  and  known  systems  have  been 
categorized  and  populated  in  the  architecture  knowledge  base,  but  no  mapping  has  been  made 
between  the  two.  This  is  a  fairly  common  situation  in  system  design  and  implementation: 
functional  experts  may  have  worked  out  the  operational  requirements,  while  system  engineers 
already  have  scoped  the  set  of  platforms  available  for  implementation  in  a  given  timeframe.  The 
role  of  the  architect  is  to  marry  the  two  for  an  optimal  solution.  Hence,  the  questions  the  architect 
will  have  to  answer,  if  he  does  not  want  to  create  a  systems  solution  from  scratch,  are:  What 
existing  systems  best  satisfy  the  stated  operational  needs?  And  how  are  system  suitability 
judgments  to  be  made? 

4.1  The  Scenario  Solution 

The  following  discussion  shows  how  an  architect  would  utilize  the  architecture  ADS  tool  to 
solve  the  problem  stated  above.  Subsequent  sections  discuss  technical  details  of  the  tool. 

We  assume  that  the  architect  starts  with  a  presentation  of  the  OV5  view  (Figure  8).  This  is  a 
graphical  depiction  in  the  architecture  ADS  tool  of  the  pertinent  OV-5  instances;  it  has  been 
condensed  down  to  certain  key  entities  for  readability.  It  shows  the  activity  model  instances  in 
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the  knowledge  base;  one  is  shown  (identified  by  textual  label),  and  others  are  hinted  at  through 
the  nested  rectangles  in  the  background.  The  architecture  ADS  tool  graphic  interface  depicts  the 
foreground  activity  model,  which  is  related  to  many  instances  of  Activity-Model-Process-Activity 
(AMP A),  of  which  one  (TRP-AO)  is  shown;  this  association  of  this  instance  with  a  single 
Process-Activity,  and  with  multiple  Activity-Model-Information-Element-Role  (AMIER)  instances  are 
shown  in  turn.  The  tool  graphical  interface  also  shows  that  the  foreground  instance  of  the 
AMIER  is  related  to  an  instance  of  Information-Element. 

This  window  lets  the  architect  select  a  specific  set  of  OV-5  instances.  Though  it’s  not  shown  in 
this  paper,  he  may  select  different  instances  than  those  in  the  foreground  by  double-clicking  on  a 
class.  The  architect  is  presented  with  the  complete  list  of  instances,  and  is  allowed  to  select  any 
of  them.  Associations  to  other  instances  are  automatically  changed:  If  he  selects  a  different 
AMP  A,  the  associated  Process-Activity,  AMIER,  and  Information-Element  instances  will  change  to 
those  related  to  the  selected  AMPA. 


Figure  8.  OV5  Window 

The  architect’s  objective  is  to  find  candidate  systems  that  satisfy  the  operational  requirements 
encapsulated  in  the  activity  model(s)  of  the  chosen  operational  view.  He  initiates  this  process  by 
clicking  the  Candidate  Systems  button.  This  action  pops  up  a  criteria  selection  window  (Figure  9). 
The  criteria  selection  window  helps  the  architect  construct  a  query  that  addresses  the  candidate 
system  selection  problem.  This  query  is  based  on  comparisons  of  slot  values  between  the  two 
views.  For  example,  OV-5  contains  information  on  the  estimated  cost  of  an  AMPA.  It  is 
reasonable  to  expect  that  an  inference  rule  in  the  knowledge  base  could  compare  system  cost  to 
AMPA  estimated  cost,  for  example,  to  assess  whether  the  budgeted  funding  for  the  process 
activity  can  cover  the  system(s)  being  analyzed  as  possible  matches. 

Even  in  these  restricted  views,  many  slot  pairs  are  candidates  for  establishing  the  comparison 
criteria  under  which  the  suitability  of  a  system  for  a  given  operational  requirement  is  to  be 
adjudicated.  Because  there  may  be  so  many  pairing  choices  an  architect  likely  will  need  help 
searching  through  them  all.  The  prototype  architecture  ADS  tool  accomplishes  this  by  grouping 
slot  pairs  based  on  data  types.  When  the  architect  clicks  one  of  the  Details  buttons  on  the  right 
side  of  the  window,  he  is  presented  with  lists  of  slots  from  each  view,  and  is  given  the 
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opportunity  to  include  them  in  the  comparison  criteria.  The  architecture  ADS  tool  aids  the 
architect  in  this  task  by  making  some  suggestions  of  its  own.  At  present  the  logic  for  how  the 
ADS  tool  generates  these  proposed  pairings  is  based  on  a  simple  slot  name  string  comparison.  A 
more  robust  logic  would  be  required  in  a  full  production-level  implementation.  The  architect 
may  include  or  remove  any  tool  generated  pre-selected  pairs  (Figure  10). 

The  architect  has  several  choices  for  how  to  build  the  comparison  operator.  Our  tests  indicate, 
for  example,  that  considering  equality  between  text  fields,  especially  free  text  fields,  is  seldom  a 
fruitful  comparison  criterion.  The  three  operators  in  Figure  10  include  equality,  but  also 
containment  (one  field  is  a  substring  of  the  other)  and  matching.  Matching  is  an  information 
retrieval  technique  based  on  a  vector  space  model  [Frakes  1992];  it  returns  a  numerical  value 
between  0  and  1 ,  inclusive,  describing  the  degree  to  which  one  text-valued  slot  matches  another. 
Matching  is  useful  for  the  decision  support  tool  because  the  user  wants  results  ranked,  not  just 
yes/no  answers. 

Currently,  the  architecture  ADS  tool  evaluations  for  how  to  match  slots  may  not  always  be 
transparent  from  the  user’s  point  of  view.  If  the  architect  is  not  satisfied  with  the  choices  given, 
he  may  match  arbitrary  slots  using  the  “Arbitrary”  line.  Arbitrary  slots  may  be  compared  using 
any  operator  that  makes  sense  for  the  domain:  equality,  containment,  and  matching,  and  also 
inequality,  less  than,  greater  than,  and  operators  of  that  ilk.  The  architect  may  also  supply 
keywords  (Figure  11).  Keyword  searches  simply  search  for  the  presence  of  that  text  string. 

Coded  slots  are  treated  specially.  As  noted,  the  descriptions  of  coded  slots  provide  more 
information  than  the  code  values.  Descriptions  are  used  when  searching  for  keywords  or 
performing  matching.  However,  equality  and  inequality  are  tested  based  on  the  code  values.  This 
heuristic  seems  most  likely  to  be  what  an  architect  intends. 


Candidate  Systems ... 

Close  | 

Figure  9.  Criteria  Selection  Window 

Once  the  architect  has  selected  the  criteria,  he  can  click  the  Search  button  in  the  Criteria 
Selection  window  (Figure  9).  The  architecture  ADS  tool  compares  all  SV-1  instances  against  the 
selected  OV-5  instance  set  according  to  the  criteria  the  user  has  established.  It  returns  a  ranked 
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ordering  of  systems,  showing  the  degree  to  which  they  satisfy  the  criteria  (See  Figure  1 1).  In  this 
way  the  architect  has  gained  knowledge  of  which  systems  are  likely  to  satisfy  the  operational 
requirements  encapsulated  in  the  activity  model(s)  for  that  architecture. 

4.2  The  Decision  Support  Tool’s  Implementation 

As  mentioned  in  Section  1,  one  of  the  goals  for  this  year’s  work  was  to  embed  inferencing  rules 
in  the  ontologies  rather  than  hard-wire  them  in  code.  This  objective  was  the  driving  factor  for  the 
design  of  the  architecture  ADS  tool. 

If  the  architecture  ADS  tool  was  to  be  rule-based,  the  next  question  was  what  rule  processor  to 
use.  We  examined  several  candidates  and  selected  Algernon  [Algernon],  Algernon  was  selected 
largely  because  of  two  factors.  First,  it  is  integrated  with  Protege:  a  version  has  been  rewritten 
specifically  for  use  with  Protege,  and  has  knowledge  of  Protege  classes.  Second,  it  can  invoke 
Java  methods,  a  benefit  that  should  not  be  underestimated.  Other  rule-based  systems  we 
investigated  were  self-contained  and  inextensible.  While  theoretically  powerful  enough,  they 
lacked  procedural  and  data  abstraction  capabilities,  and  their  use  would  have  required 
construction  of  enormously  long  and  complex  rules.  Algernon’s  ability  to  invoke  Java  methods 
lets  rule  developers  make  use  of  Java’s  abstraction  capabilities. 

The  decision  support  tool  uses  two  types  of  Algernon  rules.  The  first  are  instances  of  class 
Algemon-Path,  a  subclass  of  THING,  used  to  define  self-contained  paths,  and  its  subclass  Qualified- 
Algernon-Path.  Instances  of  the  latter  class  are  permitted  to  have  “qualifiers”,  which  are  variables 
that  are  substituted  throughout  a  path  prior  to  path  execution.  This  is  useful  for,  say,  qualifying  a 
path  such  that  it  applies  only  to  a  specific  instance  of  some  class  rather  than  all  instances  thereof. 
For  example,  one  prespecified  rule  is  AMIER  Instances  derived  from  an  AMPA,  which,  as  its  name 
implies,  takes  an  AMPA  as  a  qualifier  and  finds  all  AMIER  instances  related  to  that  AMPA. 
Without  the  qualifier,  the  path  would  find  all  instances  of  all  AMIERS  related  to  all  AMPA 
instances.  This  kind  of  rule,  then,  is  used  in  regenerating  information  in  the  tool's  graphical 
interface  view  windows  (Figure  8). 

Algernon  also  permits  forward  chaining:  the  ability  to  generate  information  based  on  discovery 
of  information.  A  forward  chaining  rule  was  useful  in  generating  the  rankings,  as  discussed 
below. 

The  user  queries  that  compare  views  are  stated  as  Algernon  paths.  These  paths  cannot  be 
prespecified  in  the  CADM  ontology,  as  the  user  causes  them  to  be  created  dynamically. 
However,  they  can  be  formulated  so  as  to  use  other  paths,  in  particular  the  forward  chaining 
rules. 
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Figure  10.  Textual  Criteria  Specification  Window 


In  other  words,  when  the  architect  clicks  the  Search  button,  the  decision  support  tool  examines 
the  selections  the  user  has  made  and  converts  these  selections  to  an  Algernon  path.  The  path’s 
purpose  is  to  create  information.  Algernon  causes  this  information  to  be  expressed  in  terms  of 
existing  classes  and  slots.  Therefore,  it  is  necessary  to  extend  the  architecture  ontology  to  model 
search  results.  Figure  13  shows  the  classes  and  template  slots  that  model  searches  in  the  CADM 
ontology.  Each  distinct  search  is  stored  as  an  instance  of  class  Search.  A  search  focuses  on 
obtaining  results  from  a  particular  CADM  class  (in  our  scenario,  SYSTEM);  the  results  of  a  search 
are,  therefore,  a  set  of  instances  of  that  focus  class.  The  CADM  ontology  models  this  as 
instances  of  Focus-CIs-lnst-Rankings,  which  has  two  template  slots:  one  that  denotes  the  focus 
class  instance,  and  a  second  to  record  the  rankings  of  that  instance  and  how  they  were  assigned. 
There  is  an  instance  of  Focus-CIs-lnst-Rankings  for  each  focus  class  found  in  the  search  (eighteen 
in  Figure  121). 


Actually,  there  are  more:  Only  non-zero  weighted  rankings  are  displayed  in  search  results. 
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Figure  11.  Keyword  Criteria  Window 


Each  Ranking  instance  denotes  a  search  category  from  Figure  9.  The  number  of  ranking  instances 
is  the  number  of  categories  the  user  has  selected  (three  in  Figure  12).  A  Ranking  instance  stores 
the  overall  ranking  value  for  a  category,  plus  the  comparisons  that  category  comprises.  Each 
comparison  is  an  instance  of  a  Comparison-Description  subclass,  recording  the  relation  used  in  the 
comparison  and  the  numeric  result  of  the  comparison.  Subclasses  of  Comparison-Description  note 
the  inputs  to  the  comparison,  supporting  reproducibility. 

The  value  slot  of  the  Ranking  class  is  the  average  of  the  values  of  the  associated  Comparison- 
Description  instances.  It  is  maintained  by  an  Algernon  forward  chaining  rule.  Algernon 
automatically  invokes  this  rule  whenever  an  Algernon  path  causes  a  Comparison-Description  to  be 
associated  with  a  Ranking.  The  rule  re-computes  the  average  and  assigns  it  to  the  value  slot. 

The  weighted  ranks  are  not  stored  as  part  of  the  search.  Weighted  ranks  are  computed  as  the 
average  of  the  search  types,  combined  with  a  weighting  factor.  This  weighting  factor  is  user- 
controlled  by  a  slider  (see  Figure  12).  Since  the  weight  is  independent  of  the  knowledge  base, 
preserving  it  serves  no  purpose. 


5  Conclusions  and  Observations 

The  extension  of  our  work  from  C2  to  DoDAF  architectures  has  yielded  some  useful 
conclusions.  We  have  succeeded  in  our  objective  to  migrate  rules  from  code  to  the  ontology. 
Though  not  shown  directly  by  the  example  in  Section  4,  the  prototype  architecture  ADS  tool  can 
support  the  comparison  of  any  two  views,  not  just  OV-5  activity  models  and  SV-1  systems.  The 
only  changes  required  are  to  include  definitions  of  the  desired  views  in  the  CADM  ontology,  and 
to  invoke  the  architecture  ADS  tool  with  parameters  specifying  these  added  views. 
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Figure  12.  Search  Results  Window 


The  results  obtained  when  executing  searches  with  a  populated  architecture  knowledge  base 
appear  to  indicate  that  more  work  is  needed  in  the  formulation  of  criteria  that  depend  mostly  on 
the  basic  coded  domains  and  textual  entries  that  CADM  allows.  As  shown  in  the  rightmost 
column  of  Figure  12  the  values  one  obtains  using  that  approach  are  rather  low,  and,  hence  do  not 
provide  sufficient  discriminatory  power  for  a  clear  selection  of  a  system  in  support  of  an 
operational  requirement  stated  in  the  OV-5  view.  The  systems  identified  as  best  meeting  the 
search  criteria  have  a  weighted  ranking  of  only  0.15. 


Figure  13.  Ontology  Classes  Modeling  Search  Results 
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One  possible  cause  of  this  problem  is  that  the  knowledge  base  was  populated  with  a  notional  data 
set  rather  than  real  architecture  examples.  The  elements  of  that  data  may  not  necessarily  be 
representative  of  the  diversity  one  might  expect  from  real  project  data.  Then  too,  the  use  of  text 
matching  via  the  vector  space  model  adopted  may  be  inherently  inadequate  in  the  absence  of  a 
more  formalistic  way  of  creating  the  description  texts  for  systems.  This  may  indicate  the  need  for 
adopting  text  templates  with  well-defined  key-words  that  all  architects  could  use.  Such  an 
architecting  process  addition  would  improve  the  results  and  justify  the  use  of  the  vector  space 
model,  which  otherwise  is  very  attractive  due  of  its  ease  of  implementation.  It  is  quite  likely  that 
better  algorithms  would  improve  the  diversity  and  magnitude  of  the  numeric  values  assigned  to 
the  rankings,  so  that  an  architect  could  use  them  for  formulating  his  systems  selection.  We 
expect  that  further  study  of  real  data  sets  will  help  resolve  this  issue. 
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Topics 

•  C2IEDM  work  at  NPS 

•  Technologies:  XMSF,  X3D,  XSBC 

•  XML  Tactical  Chat  (XTC) 

•  Exemplar:  NPS  AUV  Workbench 

•  Lessons  learned,  conclusions  and 
recommendations 
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Naval  Postgraduate  School  (NPS) 


•  U.S.  Navy’s  University 

•  Numerous  curricula,  most  sciences  &  engineering 

■  2-year  masters  degrees  with  thesis 

■  Ph.D.  research 

•  Joint,  allied  and  civil-service  students,  faculty 


■  USN,  USMC,  USA,  USAF:  -1300 

■  International  officers:  -350 

■  Faculty  -300 

•  Research  efforts  significant 

■  FY2003  reimbursables:  $90M 
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Motivation 

CPT  Mark  Murrav,  CPT  Jason  Quiqlev,  USAF 

•  Nearly  all  DoD  command  and  control 
(translate:  warfighting)  systems  connect  via 
customized  communications  “stovepipes” 

•  Automatically  Generating  a  Distributed  3D 
Battlespace  Using  USMTF  And  XML-MTF 
Air  Tasking  Order,  Extensible  Markup 

•  Stovepipes  block  interoperability 

•  XML  &  Web  Services  make  data  exchange 
much  easier 

■  Best  practices  for  syntax 

•  Still  need  coherent  consistent  context 

Language  (XML)  and  Virtual  Reality 
Modeling  Language  (VRML),  Master's 
Thesis,  Naval  Postgraduate  School, 
Monterey  California,  June  2000.  C4I 
curriculum. 

■  Best  practices  for  semantics  C2IEDM 

Slow 


Autogeneration  of  georeferenced 
Air  Tasking  Order  (ATO)  LSVEs, 
using  XML-based  Op  Orders 


MAJ  Shane  Nicklaus  USMC 


•  Scenario  Authoring  and  Visualization  for 
Advanced  Graphical  Environments 
(SAVAGE),  Master's  Thesis,  Naval 
Postgraduate  School,  Monterey  California, 
September  2001.  Information  Systems 
Technology  curriculum.  Co-advisors  Curtis 
L.  Blais  and  Dan  Boger. 
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CPT  James  Neushul  USMC  cont’d 


•  Neushul,  James  D.,  Interoperability,  Data 
Control,  and  Battlespace  Visualization  using 
XML,  XSLT and X3D,  Master's  Thesis, 

Naval  Postgraduate  School,  Monterey 
California,  September  2003.  Computer 
Science  curriculum.  Second  reader  Curtis 
Blais. 

•  http://terra.cs.nps.navy.mil/SavageProiects/ 

Students/Neushul/Work.html 


•  Two  forms  of  XML  Schema  for  C2IEDM 

■  Database  centric  -  relational  table  cross-links 

■  Only  usable  among  online  database-capable  systems 

■  Document  centric  -  hierarchal  structure 

■  human  readable  and  editable 

■  Critical  need  for  C2IEDM  usability  in  messaging 

•  Early  use  of  XML  Schema,  binary  binding 
unlocked  DTED  terrain  format 

•  New  work:  Variable  Message  Format  (VMF) 


BATTLESPACE  GENERIC  HUB  (BGH)  -  XML  SCHEMA  EXTENSIONS 
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Visualization  using  Operational  Planning 

Data,  Master's  Thesis,  Naval 
Postgraduate  School,  Monterey  California, 

September  2003.  Co-advisor  Curtis  Blais. 

•  Integrates  multiple  intelligence-related 
sources,  uses  database/XML  gueries  to 

autogenerate  Baghdad 

•  http://theses.nps.navy.mil 
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Glenn  Hodges,  MAJ  USA 


•  Map  tagset  for  Unit  Order  of  Battle  (UOB)  to 
C2IEDM 

•  Provide  database-centric  XML  Schema  for 
C2IEDM  v6.0 

•  Thesis  available  OCT  2004 
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Transformation  of  Modeling  and  Simulation: 
Meeting  the  New  Analytical  Agenda 

"  Savage,  SimKt  U.S.  Army  Combatxxl 

A  Realign  all  M&S  Models  to  /C  ^  \ 

Support  New  Analytical  Agenda 

/  ~  \  Adopt  Extensible  Modeling  &  J  1 

f  Simulation  Framework  (XMSF)  L 

r — — — \  for  Web-based  Composability  * 

Sponsor:  OPNAV  N81 

Pi’s:  Don  Brutzman,  Arnie  Buss,  Curt  Blais 

Goal:  Multiple  coordinated  world-class  modeling  projects 
to  advance  the  new  DoD  analytical  agenda.  Web-compatible 
framework  of  open  standards  +  open  source  for  analysis  by 
extending  legacy  model  interoperability,  composability. 
Technologies:  Hybrid  of  Naval  Simulation  System  (NSS), 
U.S.  Army  Combat  XXI  simulation  system  linked  via  SimKit 
discrete  event  simulation  and  Web  Services  messaging. 

Tasking  and  Deliverables  (8  total  projects) 

Analytical  Modeling  Framework:  Establish  software  framework  of 
composable  scalable  analytical  models  via  XMSF  Web  Services 
Analytical  Workbench:  Capture,  consolidate  prior  SimKit  models 
by  NPS  students  and  faculty  into  a  powerful  analytical  toolkit 
Analyses:  Perform  analyses  of  interest  to  N81  using  the  extended 
hybrid  modeling  capabilities  of  NSS/CombatXXI,  including 
_  Joint  Forcible  Entry  Options,  and  _  Improved  Strike  Module 
Force  Protection/Anti-Terrorism  Modeling:  Enhance  FP/AT  tool. 

DoD/DoN  Impact 

We’re  showing  how  to  create  an  open  marketplace  of  ideas, 
rather  than  products,  connecting  multiple  models  together 

NPS  Involvement 

•  Several  dozen  student  theses  led  up  this  project 

•  15  faculty  (MOVES,  OR)  are  participating 

•  6  staff  for  software  development,  analysis 

Milestones 

•  MORS  Symposium,  Monterey  June  2004 

•  OPNAV  presentations,  September  2004 

Partners 

•  Rolands  +  Associates  Inc.,  Metron  Inc. 

•  USMC  MCCDC,  USA  TRAC  White  Sands  &  Monterey 

•  XMSF  efforts  include  DMSO  and  additional  partners 

combine  3D  visualization,  port  defense  rehearsal,  tactical  analysis 

Special  Operations  Forces  (SOF)  Modeling:  ship-to-shore  and 

then  return,  visualized  using  SAVAGE  X3D  Model  Archive 
Advanced  Methodology:  extend/connect  model  hierarchies 
Diverse  Approaches:  multiple  Operations  Research  (OR)  theses 
Logistics:  integrated  theatre  logistics  M&S  (under  consideration) 
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NUWC  work:  TOPTIVA 


•  TASWC  OPTASK  Interactive  Viewing  Application 
(TOPTIVA) 

•  Fred  Burkeley,  NUWC  Newport  Rl 

•  C2  application  for  Multilateral  Interoperability 
Programme  (MIP)  C2IEDM 

■  presentation  of  track  and  unit  position  reports 

■  generation,  sharing,  and  presentation  of  operational 
tasking  orders 

•  Java,  OpenMap  interface,  C2IEDM  v6.0  XML, 
database 
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XML  Messaging  Key  to  systems  interoperability 

•  Fixing  message  interchange  can  be  outside 
the  code  boundaries  of  legacy  systems 

■  XML  converters  on  stovepipes  filter  input/output 

■  Avoids  rewriting  legacy  software 

■  Provides  syntactic  and  semantic  interoperability 

•  Insist  on  human  readability/fixability 

•  Beware  XML-MTF  problems 

■  Preserving  backwards  compatibility  at  the 
expense  of  cross-domain  interoperability 
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XML  in  10  Points  http://www.w3.Org/XML/1 999/XML-in-1 0-points 


s  XML  is  for  structuring  data 

*  XML  looks  a  bit  like  HTML 

*  XML  is  text,  but  isn't  meant  to  • 
be  read 

*  XML  is  verbose  by  design  • 

*  XML  is  a  family  of 
technologies 


400+  member  companies  &  institutions 
in  World  Wide  Web  Consortium  (W3C) 
already  understand  the  business  case 


XML  is  new,  but  not  that 
new 

XML  leads  HTML  to 
XHTML 

XML  is  modular 

XML  is  basis  for  RDF  and 

the  Semantic  Web 

XML  is  license-free, 

platform-independent  and 

well-supported 
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Extensible  Modeling  &  Simulation  Framework  (XMSF) 

XMSF  Partners 

•  Web  services  for  all  manner  of  M&S 

•  A  composable  set  of  standards,  profiles,  and  K&y  J 
recommended  practices  for  web-based  M&S 

•  Naval  Postgraduate  School 

■  Dr.  Don  Brutzman,  Curt  Blais 

•  Foundational  precepts:  Internet  network  technologies, 

•  George  Mason  University  (GMU) 

Extensible  Markup  Language  (XML)-based  languages, 
and  service-oriented  architectures  for  simple 

■  Dr.  J.  Mark  Pullen 

messaging 

•  SAIC  Inc. 

•  Enable  a  new  generation  of  distributed  M&S 
applications  to  emerge,  develop,  interoperate  with 

■  Dr.  Katherine  Morse 

tactical  systems 

•  Old  Dominion  University  (ODU)  VMASC 

•  Many  easily  repeatable  exemplars  using  Web  Services 

■  Dr.  Andreas  Tolk 

http://www.Moveslnstitute.orq/xmsf 
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XMSF  Sponsors 

What  is  3D? 

•  Defense  Modeling  &  Simulation  Office  (DMSO) 

•  2_D  works  for  chart-oriented  displays 

•  Navy  Modeling  &  Simulation  Management 

Office  (NAVMSMO) 

•  Defense  Threat  Reduction  Agency  (DTRA) 

•  3D  gives  “fly-thru”  freedom  of  viewpoint 

•  U.S.  Army  TRADOC  Analysis  Center  (TRAC)  Monterey 

■  View  physically  based  propagation  paths 

•  Joint  Forces  Command  (JFCOM)  Joint  Experimentation 

■  View  depth  separation 

Directorate  (J9) 

■  View  bottom,  surface  interactions 

•  Joint  Advanced  Distributed  Learning  (ADL)  Co-Laboratory 

•  USAF  Joint  Synthetic  Battlespace  (JSB) 

■  View  multiple  overlapping  sensors 

•  Chief  of  Naval  Operations  (CNO)  OPNAV  N81  - 
Assessment 

•  Augment  (not  replace)  existing  displays 

POSTGRADUATE 

POSTGRADUATE 

What  is  X3D? 

Further  X3D  motivations 

•Extensible  3D  (X3D)  Graphics 
■  Virtual  Reality  Modeling  Language  (VRML)  updated 

•Authoring  is  hard,  “Content  is  King” 

■  Third-generation  ISO  specification 

■X3D  is  not  competing  with  specialty  formats, 

■  Compatible  XML  .x3d  and  Classic  VRML  .wrl  encodings 

instead  provide  common 

•Deliverables 

interoperability/interchange 

■  Specification  updates,  with  compatible  XML  tagset 

■Strong  validation  checks  eliminate  most 

■  Multiple  implementations,  including  open-source 

authoring  errors  before  content  escapes 

■  Scene  Access  Interface  (SAI)  strongly  typed  API 

■  Conformance  suite  and  examples 

■Plays  well  with  next-generation  Web  languages 

■  Authoring  capability:  X3D-Edit,  using  XML  for  XML... 

“3D  hardware  problem”  is  already  solved  & 

^  .b3d, .b3z  \ 

/  Compressed  \ 

.  Binary  Encodings  ' 

^  / 

\  ISO  19776-3 

'  (in  progress)  / 

\ _ 


.wrl,  .wrz 
VRML  97 
Specification 

ISO  14772-2 


.x3dv 
Classic  VRML 
Encoding 

ISO  19776-2 


/  Scene  \ 

/  Authoring 
/  Interface  (SAI)  \ 

(  scripting  API  . 
for  EcmaScript  / 
\  (in  progress)  / 
JSO  19777-1  '  , 


X3D 
Abstract,  API  N 
Specifications 


ISO  19775-1,2/ 


'Ccene  Access^ 


D  19777-1  /  Interface  (SAI)  \ 

-  — '  .  scripting  API  ' 

_  _  ...  ..  ...  \  for  Java  / 

X3D  Specification  itself  is  (in  progress)  ' 
componentized,  extensible  \  iso  19777-2/ 


,x3d 
DTD,  Schema 
XML  Encoding 

ISO  19776-1 


DOM 
Document 
Object  Model 

W3C 

Recommend-  t 
ations 


X3D  now  an  ISO  international  standard 


News  Release 

N*-’  £>i*Md*nt.  W«b30  Consortium, 

Web3D  Consortium  Announces  X3D  Specification 
Approved  as  ISO  International  Standard 

Un«nimou*  vote  to  *4vinc«  X3D  ••  ISO  19775;  X3D  evolving  to  enable  and 
encourage  new  market*  for  communicating  real-time  3D 
Augu*t  9,  2004  -  SIGGRAPH  -  to*  Angela*  -  The  Web3D  Consort***  today  announced  that  the 
X30*  specific  at  on  has  been  approved  by  the  Intemabonal  Stand*,  ds  Orgwsjbco  (ISO)  as 
International  Standard  SOriCC  19773  with  formal  publicabon  expected  in  October  2004.  Developed  and 
tested  within  the  Web 30  working  group  process.  X30  is  the  Web3D  Consortium's  foundation  technology 
for  enabmg  real-time  30  communication  across  networks  and  betw*en  appl  cat  ers  and  it  was 
unanimously  approved  by  fourteen  national  committees  within  ISO.  Web 30/1  SO  specifications  for  X30. 
a  royalty-free  standard,  are  available  online  at  *<?/•»  vi  trwfrstryn. 
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XML  Schema-based  Binary  Compression  (XSBC) 


•  XML  encoding  for  validation  benefits 

•  XML  schema  contains  adequate  information 

•  Tokenization  of  elements,  attributes 

•  Strong  data  typing  of  value  payloads 

•  Lossless 

•  More  efficient  than  compressed  numeric  text 

•  Faster  parsing  and  run-time  performance 

•  Fix  potential  showstopper  to  military  XML  use 


XSBC  Compression  of  mission  scripts 


Compression  of  mission 
command  file 

XML  Schema-based  Binary 
Compression  (XSBC) 

Take  advantage  of  XML  self¬ 
validation  capability 
Building  composable  filters  for 
integrated  data  support 

Critical  capability  for  military 
communications  links 
■  Radio  frequency  (RF),  acoustic 


Forward  error  correction  (FEC) 


•  Added  redundancy  allows  receiver-side 
detection  &  correction  of  message  errors 

■  Many  military  channels  are  noisy  RF  links 

■  Avoids  “retry  until  you  die”  on  acoustic  links 

■  Big  help  on  long-latency,  low-bandwidth  links! 

•  Hamming  FEC  is  one  technique  of  several 

■  Re-exploring  Stephen  Reimers  1995  thesis 
“Towards  Internet  Protocol  (IP)  over  Seawater” 
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W3C  and  XML  Binary  Characterization 


•  World  Wide  Web  Consortium  working  group 

•  2004  charter:  establish  use  cases, 
properties,  metrics  for  evaluation 

•  2005  charter  (hopefully):  implement  and 
evaluate,  create  W3C  Recommendation 


•  Big  group,  active  meeting  schedule 

•  Progress  and  prognosis  excellent 
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XML  Tactical  Chat  (XTC) 


Use  of  Jabber  protocols 
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XTC  reference  report 


•  XML-based  Tactical  Chat  (XTC):  Requirements, 
Capabilities  and  Preliminary  Progress, 

Don  Brutzman,  Don  McGregor,  Daniel  A.  DeVos 
and  Chin  Siong  Lee  with  Saundra  Amsden, 
Curtis  Blais,  Duane  Davis,  Dimitrios  Filiagos  and 
Brian  Hittner.  Naval  Postgraduate  School, 
Monterey  California  USA,  30  November  2003. 
160  pages. 

•  http://www.Moveslnstitute.org/xmsf/xmsf.html 

#Reports-XTC 


HID:  savage@conf e rence . xchat . Moveslnsti tute.org 


mai 1  to : xmsf-contact@MovesInsti tute . org 


XTC  Tactical  Chat  S>  **  X  ®  ||r, 

Must-Have  Capabilities  http://www.jabber.org  NaTrfLtgradua?e-h»i 


Standards:  Good! 


Proprietary:  Bad! 

© 

© 


Can’t  Inspect  Binary  Messag 
Costly  Licenses,  Unpredictable  Support 
Not  Interoperable 

Can’t  Verify  Source  Code  is  Secure 
Not  Allowed  Across  Network  Boundaries 


XML  messaging,  Web  Ready 
Jabber:  Free  Software,  Open  Standards 
Can  Bridge  Multiple  Protocols 
Open  Source:  Inspect,  Modify,  Improve 
Firewall  Friendly,  Many  Applications 
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Jabber:  open-standard  XML  chat 

Military  Chat  Workshop 

•  Extensible  Messaging  &  Presence  Protocol 

•  NavySPAWAR 

(XMPP) 

•  San  Diego  California,  dates 

■  RFCs  by  Internet  Engineering  Task  Force  (IETF) 

•  Active  community 

■  Many  commercial  and  open  implementations 

■  Lots  of  activity  developing  extensions 

■  http://www.jabber.org 

•  Great  quick-start  for  chat  technology 
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Exodus  Tools  Help 


aei]  Debug  |  savage  Room  | 

savage:  XML-based  T  actical  Chal 


1/31/2004  3:20  pm]<auvrobot>  I  am  using  auvrobot.  Daryl 

1/31/2004  3:20  pm]<Java>  Testing 

1/31/2004  3:21  pmj<Java>  Testing  2 

1/31/2004  3:21  pm]<Java>  Testing  3 

2/9/2004  4:00  pm]<lee>  Mine  is  found  at  (120, 75,  5) 

2/9/2004  5:14  pm]<lee>  Hi  Don 

2/11/2004  7:56  am]<auvrobot>  Mine  is  found  at  (120, 100, 4) 

2/1 1/2004  8:05  am]<auvrobot>  Mine  found  at  position  (120, 100, 5) 

2/1 1/2004  8:05  amj<auvrobot>  Another  mine  is  found  at  location  (10, 200, 10) 

2/11/2004  9:11  am]<auvrobot>  Mine  located  at  120, 100,5 

2/11/2004  9:14  am]<auvrobot>  Mine  at  120, 100,5 

2/1 1/2004  9:24  am]<auvrobot>  A  mine  was  found  at  120, 100, 5 

2/11/2004  9:24  am]<auvrobot>  Another  mine  found  at  (50, 250, 10) 

2/11/2004  11:21  am]<auvrobot>  The  "agent"  residing  on  the  AUV  Workbench  lis 
particular  type  of  message  (e.g.  with  "Mine"  word  +3  numeric  data),  it  p 
[2/11/2004  1 1 :22  am]<auvrobot>  The  message  is  the  same  one  that  is  posted  on 
make  some  sense  out  of  the  message. 

[2/1 1/2004  12:55  pm]<auvrobot>  Mine  found  at  (100, 100, 5) 

[2/11/2004  1:23  pm)<dtdavis>  There  is  a  mine  at  50,75, 10 
[2/11/2004  1 :24  pmj<dtdavis>  There's  also  a  mine  at  200, 200, 50 
[2/11/2004  1 :24  pm]<dtdavis>  There's  a  lot  of  them  out  here,  another  mi 


o:  savage:  XML-ba 


m 


Exodus  lools  Help 


Messenger  Debug  savage  Room 


stamp='2004021 1 T1 7 :24 :22'>savage  ©conference  .xchat  .movesinstitute  .org</xxAnessagexmessage  xml:lang='en-us'  to='brutzman@xchat  .movesinstitute.org/Exodus' 
type='groupchat'  from='savage ©conference .xchat. movesinstitute .org/auvrobot'xx  xmlns='rhymbox:x:jep-0038'><name>rhymbox-1 .0</hamex/xxbody>Aiother  mine  four 
,1 0)</body><x  xmlns='jabber  :x  :delay'  from='savage  ©conference  .xchat  .movesinstitute.org'  stamp='2004021 1 T1 7:24:34'> 

)m='savage@conference.xchat.movesinstitute.org/auvrobot'xx  xmlns='rhymbox :x :jep-0038'xname>rhy mbox-1 .0</hamex/x><body>The  &quot;agent&quot;  residing  on 
s  AUV  Workbench  listens  for  . 


ry  chatroom.  The  &quot;agent&quot;  just  tries  to  make  some  s 
rg'  stamp='2004021 1 T1 9:22:1 7'> 


savage@conference.xchat.movesinstitute.org'  stamp='2004021 1 T21 :23 

to='brutzman  @xchat  me  . “ 

rhymbox-1 0</hamex/x 

stamp='2004021 1 T21 :24:05‘>savage  ©conference  .xchat.  movesinstitute  .org<Ao<Anessagexmessage  xml:lang=,en-us'  to='brutzman@xchat  .movesinstitute.org/Exodus' 

savage  ©conference  .xchat  .movesinstitute. org/dtdavis'xx  xmlns='rhymbox:x:jep-0038'xname>rhymbox-1 .0</hamex/xxbody>There&apos;s  a  lot  i 
mine  at  150, 1 50, 1 0</bodyxX  xmlns='jabber:x:delay'from='savage ©conference. xchat .movesinstitute.org'  stamp='2004021 1 T21 :24:49'> 

from='savage  ©conference  .xchat  movesinstitute  .org/au  vrobot'xx  xmlns='rhymbo 
&quot;bin/image&quot  ;</body  ><x  xmlns='jabber  :x  :delay'  from='savage  @conferenc 
avage  ©conference  .xchat  .movesinstitute  ,org</xx/message><message  type='gi 
Dm='savage  ©conference  .xchat  .movesinstitute  ,org'xsubject>savage :  XM  L-based  Tai 
Chat</bodyx/tnessage> 


ute.org/Exodus'  type='groupchat'  fro 


dus^xbody>| 
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Event  monitoring  via  instant  messaging 
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Java  1.4.2  regular  expression  parser  on  chat 


Breakdown  of  regular  expression  pattern: 


Meaningful  messages  can  be  extracted  from  chat  text, 
thus  enabling  automatic  structure  for  user  support 
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Upcoming  goals 


•  Establish  XTC  codebase 

■  Possibly  using  JFCOM  mods  to  BuddySpace 

■  Jabber/XML  throughout 

■  Open  source  Java 

■  Jabber/IRC  bridge  on  server 

■  Other  implementations  welcome 


•  Build  C2IEDM  message  templates  in  Jabber 

■  Exemplar:  NPS  fill-in  form 
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Exemplar  work  in  progress 


NPS  AUV  Workbench 
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AUV  Workbench  Project  Description 

•  Open  source,  Java,  XML,  X3D  graphics 

•  Mission  planning 

•  Robot  mission  execution 

•  Hydrodynamics  response 

•  Sonar  modeling 

•  3D  visualization 

•  Compressed  radio  frequency  (RF)  and 
acoustic  communications 
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Our  3  R’s:  rehearsal,  reality,  replay 


•  Same  needs  and  capabilities  for  each: 
mission,  visualization,  data  support,  etc. 

•  Refining  AUV  workbench  to  support  each 

■  caveat:  ongoing  work  in  progress 

•  10  years  of  effort  now  coming  to  fruition 

■  integrating  great  variety  of  successful  work 

■  Everything  online:  source,  bugs,  email,  chat,  etc. 

•  Collaboration  is  welcome 


6DOF  response 
hydrodynamics 


robot 

execution 


j£=i£d£. 


mission 

commands 
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Physical  modeling 


•  Control  algorithms  and  6  degree-of-freedom 
(6DOF)  hydrodynamics  response 

•  Sonar  propagation,  attenuation 

•  Collision  detection 


■  Direct  vehicle  contact  and  sensor  contact 

■  Separate  use  of  same  X3D  graphics  models 

•  Visualization  greatly  aids  understanding 

■  provides  good  “forcing  function”  for  integration 
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sonar-vis  Project  Description 


•  Visualize  multipath  3D  sonar  propagation 

■  Situational  awareness,  sensitivity  analysis 

■  Multiple  models:  path,  transmission  loss,  PD  ... 

■  Operator  familiarization,  training,  experience 

•  Enhance  TDAs  for  at-sea  operators 

■  Reachback  using  Web  services  messaging, 
accessing  both  computational  and  data  assets, 
locally  and  from  shore-side  supercomputers 

■  Open  source  open  standards:  Java,  X3D,  XML 
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Integrating  2D/3D  interfaces  with  Web  Services 


Participating  in  RIMPAC,  UD  2004  exercises 


InpSL  naval  JS P'?S| 
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XML  web  services  for  METOC  data  2 

•  Monitoring  initial  query/response  sequence 

- - - - - - - - - 

r:™ 
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Next  steps,  lessons  learned, 

conclusions,  recommendations 
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Demonstrations  at  l/ITSEC  2004 

•  Interservice  Industry  Training  Simulation  Education 
Conference  (l/ITSEC) 

■  December  6-9,  Orlando  Florida 

•  Multiple  demonstrations  across  show  floor 

■  X3D,  XMSF,  XSBC,  XTC,  C2IEDM 

■  Multiple  government,  industry  partners 

■  multiple  domains  &  locations  connected:  supercomputer, 
underwater/airborne  robots  in  Monterey,  George  Mason 
University  Fairfax  VA,  NUWC  Newport  Rl,  etc. 

•  http://www.iitsec.org 
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Lessons  learned 

•  XML,  web  services  are  ready  for  prime  time 

•  Robots  are  potential  “C2IEDM  speakers”  too 

■  Along  with  people  (operators)  and  C4I  systems 

•  Binary  XML  compression  is  essential  for 
military  communications  links 

■  Radio  frequency  (RF),  acoustic,  etc. 

•  It’s  really  all  about  the  XML  messaging 

■  Not  just  heavyweight  database  synchronization 

•  XML  Tactical  Chat:  shared  real-time  comms 
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Conclusions 


•  C2IEDM  has  much  promise 

■  Even  more  than  shown  in  current  C4I  systems 

•  Rich  mix  of  compatible  XML  technologies 

■  X3D:  Extensible  3D  graphics 

■  XMSF:  Web  services  for  modeling  &  simulation 

■  XSBC:  Binary  compression  of  XML 

•  New  XML-based  capabilities  are  emerging 

•  Interoperability  on  everything 
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Recommendations 


•  Need  a  document-centric  XML  version  of 
C2IEDM  to  support  military  messaging 
■  Is  there  a  review  forum  or  standardization  effort? 


•  XML  tactical  chat  is  a  new  message  channel 

•  Plan  for  robots  as  emerging  players 

•  When  wrapping  and  unlocking  stovepipes 
with  XML  messaging,  use  C2IEDM 

•  Build  exemplars  -  walk  the  walk 


Collaboration  and  questions  welcome 
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Contact 


Don  Brutzman 

brutzman@nps.navy.mil 
http://web.nps.  na  vy.  mil/~brutzman 

Code  USW/Br,  Naval  Postgraduate  School 
Monterey  California  93943-5000  USA 
1.831.656.2149  voice 
1.831.656.7599  fax 
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Next  Generation  Distributed  Sensor  Networks 


S.  S.  Iyengar1 ,  G.  Seetharaman4,  R.  Kannan1,  A.  Durresi1,  S.  Park1 ,  B.  Krishnamachari2 

R.  R.  Brooks3  and  J.  Morrison4 1st  LT  USAF 

'Dept  of  Computer  Science,  Louisiana  State  University,  Baton  Rouge,  LA70803-4020 
2Dept  of  Computer  Science,  Univ  of  Southern  California,  Los  Angeles 
Dept  of  Computer  Science,  Clemson  University,  NC 
4AFIT  ENG,  Air  Force  Institute  of  Technology,  WPAFB,  OH 


1.  ABSTRACT 

Distributed  sensor  networks  operating  through  wireless  communication  offer  a  powerful  means 
to  sense,  analyze  and  respond  to  dynamic  environments  spread  over  vast  areas.  Latest 
developments  in  micro  electro  mechanical  sensors  (MEMS)  and  related  devices  offer  several 
technical  and  operational  advantages  making  distributed  sensor  networks  as  a  viable  approach. 
Robustly  packaged,  inexpensive,  energy  aware  and  tamper  proof  sensors  deployed  in  massively 
as  an  ad-hoc  wireless  sensor  network  add  a  whole  new  dimension  to  several  high  impact 
applications  such  as  air  port  surveillance,  traffic  monitoring,  environmental  monitoring, 
surveillance  against  bio-terrorism,  battle  field  damage  assessment  etc.  In  short  they  permit 
pervasive,  persistent  and  high  endurance  monitoring  of  hostile  environments.  This  paper  is  an 
introduction  to  some  of  the  exciting  information  processing  problems  that  are  being  solved  to 
effectively  harvest  the  benefits  of  current  and  emerging  nano,  micro,  and  macro  sensors  in 
distributed  sensor  networks. 


2.  BACKGROUND 

Nano  technology  is  one  of  the  intensely  researched  areas  at  present.  A  number  of  nano  and 
micro  sensors  are  being  introduced  each  month  ranging  from  biological  sensors  to  complex  RE 
and  optical  sensors.  The  mass  volume  production  and  inexpensive  fabrication  of  these  sensors 
make  them  a  viable  candidate  to  propel  the  art  of  surveillance  and  monitoring  of  wide  spread 
areas.  Adding  fuel  to  this  idea  is  long-life  batteries,  energy  aware  CMOS  circuit  designs,  and 
hybrid  CMOS-MEMS  integration  techniques  which  are  at  the  forefront  of  technology.  An 
impressive  array  of  packaging  techniques  exist  and  new  ones  are  being  steadily  developed  to 
help  deploy  these  sensors  in  hostile  conditions  in  large  numbers. 

Most  hostile  conditions  and  events  of  single  occurrence  do  not  permit  redeployment  or 
replenishing  of  the  batteries  in  situ  the  sensors.  Also,  it  is  not  possible  to  pre  identify  the  network 
topology.  It  is  required  to  have  a  systematic  way  of  establishing  a  network  among  the  sensors 
after  they  have  been  deployed,  and  gather  information  robustly  in  a  maximally  pervasive, 
persistent  and  enduring  fashion.  Sophisticated  information  processing  tasks  must  factor  this  into 
account. 

The  September,  1999,  edition  of  Business  Week  stated  that  the  next  generation  of  distributed 
sensor  networks  introduces  important  new  technologies  for  the  21st  century.  Likewise,  the 
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February,  2003,  edition  of  MIT’s  Technology  Review  identified  sensor  networks  as  one  of  the 
top  ten  emerging  technologies.  The  July  2003  issue  of  the  IEEE  Proceeding  is  devoted  to  micro 
and  nano  sensors.  The  August  2004  issue  of  IEEE  Computer  Magazin  gives  an  excellent 
introduction  to  the  state  of  the  art  in  wireless  sensor  networks. 

The  motivation  for  sensor  systems  is  the  intelligent  gathering  of  sensor  data,  processing  the  data, 
and  understanding  and  controlling  the  processes  inherent  to  the  system.  Pervasive  micro  sensing 
and  actuation  has  revolutionized  the  design  and  management  of  extremely  complex  physical 
systems.  The  revolutionary  shift  in  paradigm  is  very  similar  to  the  invention  of  SIMD  parallel 
computers  in  the  late  seventies.  The  focus  at  that  time  was:  instead  of  building  one  very  high 
performance  computer,  a  well  conceived  network  of  very  simple  processors  could  be  built  and 
operated  in  single  instruction  multiple  data  mode  to  accomplish  very  high  performance 
computing.  The  Connection  Machine,  and  MassPar  machines  built  using  this  approach  have 
demonstrated  the  merit  of  this  approach.  A  similar  revolution  is  taking  place  in  surveillance  and 
monitoring  techniques  based  on  large  network  of  very  simple  sensors  and  extremely  simple 
network  topologies. 


3.  INTRODUCTION 

Sensor  networks  can  be  viewed  as  a  distributed  autonomous  system  for  information  gathering, 
performing  data-intensive  tasks  such  as  environment  (habitat)  monitoring,  seismic  monitoring, 
terrain  surveillance,  etc.  Each  node  of  the  network  must  consist  of  three  components:  1)  a  variety 
of  sensors  to  acquire  information  about  the  observed  space;  2)  a  wireless  communication  system 
to  help  move  the  data  to  end  user  via  the  neighbors;  3)  a  computing  /  coordinating  system  to 
buffer  the  data,  and  perform  higher  level  task  related  to  forming  and  operating  within  an  ad-hoc 
network.  The  computing  part  makes  it  capable  of  energy  aware,  adaptive  operation,  fault 
tolerant,  and  tamper  proof. 

Elements  of  a  sensor  network  include  the  sink  which  sends  queries  and  collects  data  from 
sensors,  and  the  sensor  which  monitors  phenomenon  and  reports  to  sink  (Figure  1).  Typically 
the  outsider  (sink)  does  not  communicate  invasively  to  an  arbitrary  element  in  the  network;  his 
query  would  be  picked  up  by  a  nearest  node  in  the  boundary,  or  by  one  of  a  few  pre-selected 
subset  of  nodes.  Since  communication  with  a  distant  sink  takes  more  energy,  a  typical  node 
should  avoid  communicating  directly  to  the  sink.  Thus,  there  is  an  asymmetry:  the  sink  can 
broadcast,  but  the  nodes  should  not  reply  directly.  There  is  an  implicit  tradeoff  of  involving 
latency  for  prudent  use  of  power  in  favor  of  endurance. 

Wireless  sensor  networks  are  usually  a  large  number  of  sensor  nodes  that  can  be  readily 
deployed  in  various  types  of  unstructured  environments.  They  rely  on  wireless  channels  for 
transmitting  and  receiving  data  from  other  nodes.  Often,  the  deployment  mechanisms  do  not 
permit  control  over  the  spatial  manifest  of  the  network  topology.  The  sensors-nodes  must  have 
native  capabilities  to  detect  the  nearest  neighbors  and  help  to  develop  an  ad-hoc  network  through 
a  set  of  well  defined  protocols. 
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Figure  1:  Sink  and  Sensors 


Commercial  off  the  shelf  (OTS)  components  are  available  to  provide  the  wireless 
communication  aspects  of  the  nodes,  allowing  the  researchers  to  focus  their  effort  on  the  sensor 
design,  and  analysis  of  sensed  data.  Thus,  a  typical  node  of  a  generic  sensor  network  is 
envisioned  as  a  hybrid  structure  made  of  custom  designed  sensors  packaged  with  OTS  (re)motes 
shown  below.  A  typical  sensor  mote  consists  of  sensing  elements,  battery  (AA  size),  processor 
(less  than  20MHz),  memory  (less  than  1MB)  and  communicating  equipment.  Figure  2  is  an 
example  of  a  typical  sensor  node,  also  widely  known  as  the  mote. 
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Figure  2:  Typical  sensor  node.  Adapted  from  Courtesy  Crossbow,  Inc. 

Sensor  network  nodes  may  consist  of  many  different  sensor  elements.  A  Sensorcraft  [10]  is 
being  developed  to  accommodate  a  wide  range  of  sensors  in  a  single  mobile  platform.  In  this 
case,  it  is  a  small  air  craft  designed  carry  advanced  electromagnetic  sensors  based  on  RF-MEMS, 
FLIR  cameras,  and  CMOS  based  cameras,  an  assured  data  link,  onboard  GPS  and  atomic 
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precision  time-reference  circuitries.  Another  article  from  AFRL  Horizons[ll]  depicts  a 
heterogeneous  network  envisioned  by  AFRL  with  sensors  operating  in  concert.  Some  nodes  of 
the  network  remain  at  fixed  positions,  whereas  other  nodes  (aircraft)  remain  in  constant  motion. 
Communications  travels  from  aircraft  to  ground  sensors,  and  vice  versa.  The  network  nodes  also 
offer  a  wide  range  of  sensing  and  communication  capabilities,  including  distributed  ground 
based  sensor  networks  clustered  together  to  act  as  a  single  sensor  node.  Some  configurations 
will  wait  to  be  probed  by  a  flyby  sink,  while  others  may  risk  exposure  to  report  critical  events 
albeit  with  measured  risk. 

A  challenge  in  distributed  sensor  networks  is  developing  an  efficient  and  effective  method  of 
extracting  data  from  the  network.  Figure  3  shows  an  example  of  sensor  network  interaction  in 
which  a  user  submits  a  query  to  the  network.  In  this  example,  the  query  is  submitted  to  the 
network  through  a  sink,  and  is  then  forwarded  to  the  sensor  nodes  by  local  communications 
links.  However,  if  the  same  node  were  to  always  host  sink  communications,  then,  that  node  will 
consume  battery  power  faster  than  other  less  active  nodes.  Also,  given  a  limited  amount  of 
memory  per  sensor  node,  an  efficient  method  of  handling  communication  buffer  overflows  must 
also  be  devised. 


Figure  3:  Network  of  typical  sensor  nodes. 


A  sensor  network  is  an  embedded  system  that  should  have  the  following  properties: 
Self-Configuration  -  formation  of  networks  without  any  human  intervention 
Self-Healing  -  automatic  deletion/addition  of  nodes  without  resetting  the  entire  network 
Dynamic  Routing  -  adapting  routing  schemes  on  the  fly  based  on  the  network  conditions 
like  link  quality,  hop  count,  gradient,  etc. 

Multi-Hop  Communication  -  improving  the  scalability  of  the  network  by  sending 
messages  peer-to-peer  to  a  base  station. 

Three  common  traffic  methods  to  explore  in  a  sensor  network  are  many-to-one,  one-to-many, 
and  local  communication.  The  many-to-one  method  has  the  sensor  nodes  sending  data  to  a  base 
station  or  aggregation  point  in  the  network.  For  the  one-to-many  method,  a  base  station  or  single 
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node  under  a  specific  condition  multicasts  or  floods  a  query  or  control  information  to  several 
sensor  nodes  or  neighbors.  For  the  local  communication  method,  nodes  exchange  localized 
messages  to  locate  and  coordinate  with  each  other.  The  local  communication  messages  may  be 
broadcast  or  unicast  messages  [1]. 

Sensor  networks  are  usually  used  for  either  data  gathering  or  an  event  detection.  For  data 
gathering,  data  should  be  gathered  from  the  sensor  nodes  in  periodic  cycles.  A  challenge  here  is 
to  guarantee  the  system  lifetime.  For  example,  communications  should  occur  such  that  a  single 
node  is  not  burdened  with  all  communications  to  the  sink.  For  event  detection,  sensing  should 
occur  in  real-time.  Communication  to  the  base  station  should  be  performed  only  upon  the 
detection  of  a  required  event.  For  both  data  gathering  and  event  detection  networks, 
measurements  from  the  sensors  should  be  correlated  in  order  to  aggregate  data.  The  sensors 
should  also  cluster  to  facilitate  aggregation  and  protocol  scalability. 

4.  HIGH  IMPACT  APPLICATION  OF  W-DSNS 

Distributed  sensor  networks  can  be  innovatively  applied  to  a  variety  of  domains  (Figure  4). 
Military  applications  include  surveillance,  target  tracking,  and  characteristics  measurement  of 
incoming  targets. 


Figure  4:  Applications  domains 


The  advance  of  MEMS  technology  provides  new  opportunities  for  distributed  sensor  networks. 
MEMS  are  small,  use  little  power,  and  are  bulk  produced.  The  Jammer  Location  System 
(JLOCS)  [12]  follows  a  network  centered  approach  to  detecting  the  jamming  signals  through  a 
widespread  set  of  GPS  devices  acting  as  jamming  sensors.  It  is  required  that  we  know  the  self 
position  of  the  sensors,  swiftly  determine  the  direction  of  arrival  (maximum  reception)  and 
establish  a  precise  baseline  for  triangulation.  RF  MEMS  provide  ability  to  generate  high  radio 
frequencies  in  order  to  super-heterodyne  a  jammed  high  frequency  signal  to  much  lower 
frequencies.  At  lower  frequencies,  the  beat  patterns  between  jammed  signals  and  the  jamming 
signals  are  efficiently  measured  and  characterized  to  determine  the  jammer’s  location. 

Another  use  of  MEMS  sensors  is  measuring  sound  and  pressure  activity  to  determine  the 
location  of  a  seismic  or  acoustical  event.  The  Sniper  Location  System  (SLOCS)  (Figure  5)  [13] 
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uses  sensor  nodes  with  numerous  MEMS  sensors  each  to  measuring  its  self  location,  time-of- 
arrival,  and  angle  of  arrival  of  shock  waves.  At  least  two  sensors  per  soldier  is  essential  to 
measure  phase  difference  and  hence  angle  of  arrival.  The  sniper  location  and  projectile  path  may 
be  determined  from  these  measurements. 


Interest  is  also  growing  in  methods  of  employing  stealthy  and  sacrificial  nodes.  This  challenge 
addresses  the  conflicting  interest  of  actively  sensing  while  maintaining  stealth  (low 
observability).  A  sacrificial  node  may  be  chosen  to  emit  the  energy  for  active  sensing,  thus 
disclosing  its  location.  However,  the  remaining  sensor  nodes  maintain  stealth  as  they  collect  the 
resulting  measurements.  One  or  more  UAYs  act  as  sacrificial  nodes  for  networks  to  help  acquire 
data  from  other  stealth  aircrafts.  Atomic  precision  clock  is  necessary  to  coordinate  the  events. 
Current  state  of  the  art  in  modeling  sensor  nodes  do  not  factor  in  the  mobility  and  exposure 
(intentional  risking  of  stealth).  They  do  not  focus  on  the  time  varying  spatial  configuration  of  the 
sensors,  which  may  be  manifesting  as  an  elastic  mesh,  in  a  collective  motion.  Inclusion  of  such 
factors  would  be  of  vital  value  to  problems  focused  by  the  micro  UAV  based  SWARM  sensing 
program,  and  the  DARPA  MANTIS  program. 

Another  practical  example  we  are  studying  deals  with  wide  area  video  surveillance  of  busy 
places  like  airport  corridors  populated  with  steadily  moving  humans.  Here  the  objective  is  to  use 
inexpensive  CMOS  digital  video  cameras,  with  localized  computing,  and  wireless 
communication  capabilities.  The  wireless  is  chiefly  needed  for  inexpensive  and  rapid 
deployment  purpose  only.  The  networked  sensing  is  necessary  to  help  construct  high  resolution 
images,  and  be  able  to  human  gestures.  These  requirements  can  not  be  accomplished  by 
traditional  approaches,  where  only  a  few  cameras  are  used  to  image  the  corridor  from  a  few 
strategically  selected  locations.  Such  systems  are  inevitably  forced  use  wide  angle  lenses,  and 
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large  depth  of  field  of  imaging,  resulting  in  a  low  pixel  count  of  any  observed  object.  A  super 
resolution  imaging  would  track  the  subject  as  he/she  moves  in  the  field  of  view,  and  inverse 
compensate  the  motion,  and  fuse  the  video  into  a  high  resolution  image.  In  this  case,  from 
information  theoretic  point  of  view,  the  motion  must  be  extracted  from  sources  other  than  video. 
A  large  network  of  extremely  simple  motion  sensor,  and/or  line  of  sight  optical  sensors  prove  to 
be  effective.  Initial  results  are  encouraging  [14].  Once  again,  the  choice  of  implementing  this  by 
a  wireless  sensor  network  is  primarily  driven  by  the  economic  and  logistics  constraints  rewiring 
a  building  to  deploy  the  sensors. 

Another  exciting  application  deals  with  early  detection  of  onset  of  insidious  viruses.  The  DSN 
approach  to  this  problem  would  require  a  set  of  geo-sparse  internet  nodes  equipped  to 
communicate  amongst  themselves  through  a  channel  other  than  the  Internet.  These  nodes  form  a 
graph.  Each  node  is  able  to  monitor  localized  traffic  over  a  periodic  interval  and  compute  a  local 
activity  vector  for  each  period.  All  nodes  do  so  in  a  synchronized  fashion.  At  the  end  of  each 
period,  each  nodes  communicates  with  its  neighbors  its  qualitative  assessment  of  the  health 
(activity),  and  the  traffic  (port-wise)  measure.  Then,  a  discrete  relaxation  technique  would  help 
compute  the  health  of  a  specific  node,  based  on  the  perceived  health  of  its  neighbors  (last  frame), 
and  their  pair-wise  dealings  (packet  statistics)  over  the  last  frame.  This  method  is  easy  to 
implement.  Analytical  tools  exist  in  Computer  Vision  and  Artificial  Intelligence  to  interpret 
relaxation  based  results. 

For  catastrophic  events  such  as  chemical  or  nuclear  accidents/attacks,  methods  to  rapidly  deploy 
chemical  and  radiation  sensor  networks  should  also  be  developed.  Sensor  networks  designed  for 
these  events  should  provide  real-time  monitoring  information  for  response  and  rescue  missions. 
Such  systems  could  have  been  valuable  for  several  incidents: 

Dec  3,  1984  -  gas  leaked  from  a  tank  of  Methyl  Isocyanate  in  Bhopal,  India,  leaving  4000 
dead  and  thousands  of  people  permanently  disabled. 

March  20,  1995  -  terrorist  released  sarin  an  organophosphate  (OP)  nerve  gas  in  Tokyo 
subway  system  killing  1 1  and  injuring  5500  people. 

Feb  6,  2001  -  A  leak  of  titanium-tetrachloride  at  the  Tamworth  heat  treatment  factory  of 
Staffordshire,  UK,  resulted  in  more  than  50  injuries. 


5.  KEY  CHAEEENGES :  COORDINATED  COMMUNICATION  ALGORITHMS 

There  is  still  a  great  deal  of  research  and  development  work  to  be  done  in  distributed  sensor 
networks.  Before  resource-constrained  sensor  networks  can  be  deployed  at  large  scale  for  long 
durations  in  harsh  environments,  a  number  of  fundamental  technical  problems  need  to  be  solved, 
such  as: 

Self-Configuring  Deployment  and  Coverage 
Efficient  Medium  Access 

Intelligent  Self-Organizing  Routing  and  Querying 
Information  Management  and  Distributed  Control 
Fault  Tolerance  and  Robust  Operation 
Information  Security  and  Attack-Countermeasures 
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Addressing  these  technical  problems  requires  to  cutting  across  all  layers,  from  physical  and  link 
to  network  and  application-level.  Their  solutions  require  the  application  of  state-of-the-art 
sophisticated  theoretical  techniques  from  many  disciplines:  coding  theory,  game  theory, 
distributed  control,  complexity  theory  and  approximation  algorithms,  Bayesian  inference, 
network  security. 


Sensor  eost:  $200 
Detection  range:  200m 


1 00m  between  grid  points 

Figure  6:  An  example  from  of  a  deployment  and  coverage  problem  in  a 
two-dimensional  sensor  field. 

Recently,  we  have  begun  forging  collaboration  between  LSU,  faculty  at  Clemson  (Brooks),  and 
the  University  of  Southern  California  (Krishnamachari)  to  tackle  these  challenges.  At  AFIT  we 
are  investigating  MEMS  enabled  assured  reference  devices  in  JLOCS,  SLOCS.  Also,  early 
warning  virus  onset-detectors  using  collaborative  agents  across  the  internet  are  also  being 
investigated. 

Some  of  our  preliminary  work  is  addressing  the  question  of  how  heterogeneous  sensors  should 
be  deployed  to  ensure  coverage  and  connectivity  goals  are  satisfied  within  cost  constraints. 
Coding  Theory  techniques  such  as  Identifying  Codes  are  useful  for  addressing  deployment  and 
coverage  problems  such  as  is  shown  in  Figure  6  [2], 

Another  area  we  are  studying  is  the  efficient  access  to  the  communication  medium.  To  save 
energy,  distributed  algorithms  (Figure  7)  have  been  developed  to  coordinate  sleep  schedules  of 
nodes  to  conserve  energy  while  keeping  communication  delay  within  acceptable  levels  [3]  [4], 
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Figure  7:  Sample  graph  of  algorithm  to  coordinate  node  communications 

for  efficient  medium  access. 


Also,  we  have  proposed  Game  Theoretic  routing  models  for  reliable  path-length  and  energy- 
constrained  routing  with  data  aggregation  [5].  In  this  model  each  node  (player)  will  tend  to  link 
to  the  healthiest  possible  node  (the  network  partition  will  be  delayed).  Each  node  shares  the  path 
length  cost,  with  path  lengths  tending  to  be  as  small  as  possible.  Smaller  path  lengths  prevent 
too  many  nodes  from  taking  part  in  a  route,  reducing  overall  energy  consumption.  The  Nash 
Equilibrium  of  this  routing  game  defines  the  optimal,  Length-Energy-Constraint  (LEC)  path  [5]. 


Because  interoperability  between  different  nodes  in  a  large  scale  sensor  system  is  inherently 
difficult,  we  have  developed  and  evaluated  a  number  of  controller  design  methodologies  for 
hierarchically  controlling  the  behavior  of  distributed  sensor;  including  Petri  Net,  finite  state 
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automata  (FSA),  and  vector  addition  control  (VAC)  [6].  Also,  we  have  developed  a  Bayesian 
interface  technique  to  differentiate  between  measurement  errors  and  significant  environmental 
anomalies  based  on  localized  evidence  [7].  This  technique  can  correct  more  than  90%  of  errors 
if  the  fault  rate  is  less  than  10%. 

We  have  also  worked  on  several  routing  techniques  with  in-network  information  fusion  in  order 
to  aggregating  information  as  much  as  possible  (Figure  9)  [8]. 


Scheme 

Bits  Used 

Savings 

Response  Quality 

No  aggregation  (NA) 

221544 

0% 

Exact 

Header  Aggregation  (HA) 

117544 

46.9  % 

Exact, 

HA  with  Compression  (HAC) 

100648 

54.6  % 

Exact 

Rectangular  Aggregation  (R.A) 

34984 

84.2  % 

Tight  rect.  approximation 

Circular  Aggregation  (CA) 

34984 

84.2% 

Tight  circ.  approximation 

Stepwise  Rect.  Aggregation  (SRA) 

9240 

95.8% 

Tight  rect.  approximation 

Figure  9:  Evaluation  of  several  routing  and  aggregation  schemes. 

We  are  also  addressing  network  security  requirements  given  the  severe  resource  constraints,  as 
traditional  cryptographic  techniques  have  unacceptable  overhead.  One  recent  development  of 
new  distribution  protocol  providing  an  efficient  tradeoff  between  security  and  performance 
resulted  in  a  2-phase  technique  that  provable  outperforms  state-of-the-art  randomized  techniques 
at  new  key  [9]. 

Our  next  challenge  addresses  interoperability  with  Internet  and  Actor  networks.  In  an  Actor 
Network,  an  external  user,  such  as  a  commander,  orders  actors  to  perform  actions  such  as 
changing  the  environment  or  attacking  targets  (Figure  10). 


Commander 


Actors 


Figure  10:  Depiction  of  an  interaction  between  a  sensor  network  and  an  Actor  network. 
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The  issues  for  interoperability  between  these  networks  include  development  of  standard 
interfaces,  authentication  and  security,  and  coordination.  Due  to  different  protocols  at  the 
sensor,  actor  network,  and  Internet,  it  is  necessary  to  provide  common  and  extensible  interfaces. 
Hostile  forces  make  critical  the  need  to  provide  decentralized  authentication  methods  over 
Internet  or  shared  wireless  media.  Furthermore,  all  autonomous  sensor  and  actor  networks 
should  collaborate  with  each  other  without  human  coordination.  These  are  the  challenges  that 
the  new  technology  and  new  ways  of  thinking  have  brought  in  the  area  of  distributed  sensor 
networks. 


6.  CONCLUSION 

Current  trends  in  MEMS  and  NEMS  sensors  indicate  increased  availability  of  inexpensive  and 
massively  deployable  sensors  to  help  monitor  hostile  environments  through  wireless  sensor 
networks.  Steady  progress  in  power  aware  CMOS  circuits,  increased  access  to  CMOS-MEMS 
hybridization,  operational  advantages  of  RF-MEMS  antennas  all  make  wireless  sensor  network  a 
common  place  infrastructure  of  the  near  future.  Recent  research  has  been  focused  on  both 
communication  and  protocols  required  to  operate  these  sensor  networks.  We  have  presented  a 
number  of  promising  applications  currently  being  studied,  along  with  specific  communication 
algorithms  developed  to  perform  the  power  aware  routing.  Security  is  an  important  factor  which 
has  not  been  covered  here  since  it  is  covered  by  a  number  of  papers  in  literature. 
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Network  Security  Issues  for  the  GIG 

Dr.  Scott  Hansen 

Northrop  Grumman  Defense  Missile  Systems,  Reston,  VA 

This  talk  addresses  some  of  the  Information  Assurance  (IA)/Security  issues  that  we  will  be 
addressing  in  the  Homeland  Security  and  Defense  spaces  in  the  near  term  as  we  wrestle  with  the 
aftermath  of  the  9/11  incident. 

I'm  going  to  talk  a  little  bit  about  some  of  the  vision  in  the  GIG  and  the  analogous  homeland 
security  vision  and  then  talk  some  about  the  constraints  that  are  coming  down  from  both  sides  of 
the  problem  space.  There  are  two  major  IA/Security/Network  task  forces  in  our  nation  underway, 
looking  at  the  netcentric  IA/Security  and  what  are  the  various  issues,  these  task  forces  are  under 
the  GIG  IA  SPO  at  the  NS  A  and  the  other  one  is  organized  under  the  Markle  Foundation.  I  am 
sure  most  everybody  in  this  room  knows  the  NS  A  and  their  work.  How  many  people  are 
familiar  with  the  Markle  Foundation  task  force  identified  by  the  9/11  Commission  as  having  a 
reasonable  approach  to  information  sharing  that  might  have  prevented  the  9/11  incident? 
Anybody  in  the  room?  OK.  Maybe  I  better  spend  a  minute  on  that  Task  Force.  This  was  the 
task  force  that  was  stood  up  to  look  at  the  9/11  terrorist  incident  and  determine  what  went  wrong 
and  what  do  we  as  a  nation  need  to  do  about  it  to  prevent  a  future  occurrence.  Not  surprisingly 
they  ended  up  with  a  network  vision  that  looks  an  awful  lot  like  the  GIG  and  so  I'll  talk  a  little  bit 
about  this  turn  of  events  and  how  these  are  driving  the  solution  set  that  is  evolving  in  our  nation 
today.  Then  I’ll  say  a  few  words  about  the  environments  that  are  going  to  be  different  between 
Homeland  Security  and  Homeland  Defense.  Both  Warfighting  and  Homeland  Security  have 
some  unique  aspects.  I’ll  also  discussion  some  data  origination  and  relevant  time  scales  that  are 
largely  different  from  the  Homeland  Security  problem,  and  I'll  talk  to  you  about  those 
differences  and  effects  within  the  decision  support  environment. 

This  slide  [Slide  2]  illustrates  the  evolutionary  transition  plan  for  the  GIG.  There  are  three  major 
increments  within  the  GIG  vision  with  deliveries  from  2008  -  2016.  Increment  one,  two  and 
three  going  out  a  number  of  years  and  this  is  to  bring  all  the  networks  together  and  give  us  that 
common  network  backbone  in  the  DoD  that  was  just  discussed  in  this  vision. 

Interestingly  enough  going  over  onto  the  other  side  of  Homeland  Security  [Slide  3],  in  the  next 
slide,  and  to  Mr.  Cooper  and  DHS  and  you  find  a  very  similar  set  of  problems  and  vision  looking 
for  that  single  converged  network  backbone  migrating  from  a  US  Secret  backbone  which  DoD 
and  DHS  are  starting  with  to  a  multi-  level  secure  environment  that  they  have  to  end  with  in 
some  future  time  frame.  We  talk  about  complexity  in  coalition  warfare  but  this  HLS/DoD 
coalition  that  is  you  and  I,  and  the  cop  on  the  street  and  your  private  company  that  is  a  much 
more  complex  coalition  than  we  are  used  to  dealing  with  in  the  DoD  arena  and  will  have  a  very 
complex  rule  set.  We  can  easily  have  people  running  around  with  our  personal  privacy  and 
corporate  data  that's  suddenly  part  of  the  terrorism  war  when  we  deal  with  US  operations.  This 
personal  liberty  and  private  infrastructure  aspect  that  has  to  be  brought  into  the  decision 
processes  makes  the  problem  very  different  than  we  have  dealt  with  to  date.  We  have  to  worry 
about  gatewaying  information  now  and  it's  not  just  between  the  DoD  and  the  Global  Information 
Grid,  it  goes  right  on  down  to  the  state  and  local  level  where  the  Governor  is  responsible  for  the 
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war  against  terrorism  in  his  state.  Very  serious  issues  of  Title  10,  Title  32  activity  and  who 
controls  which  data  when,  how  can  it  be  used,  what's  the  governor  signing  up  for,  what's  the 
DoD  signing  up  for,  what's  Homeland  Security  signing  up  for  are  some  of  the  major  issues. 
Make  no  mistake  about  this  activity  as  its  expected  to  dynamically  collaborative  and  it  will  be 
very  temporally  dynamic  as  the  situation  presents  itself  that  was  only  vaguely  defined  before. 


Slide  2 


Slide  3 


This  is  the  first  Increment  of  the  GIG  illustrated  on  this  slide  [Slide  4]  that  is  expected  to  be 
completed  by  2008,  I  don't  know  how  many  dates  I  really  trust  in  any  of  this,  but  essentially 
what  happens  the  way  we  are  set  up  today  we've  got  a  top  secret  network  up  at  the  top  with  all 
the  various  security  caveats  riding  it,  SIPRNET  with  all  the  US  Secret  and  collateral  information 
and  then  finally  the  Sensitive  But  Unclassified  (SBU)  net  down  at  the  bottom  are  illustrated  on 
this  slide.  And  the  first  step  is  to  put  a  black  core  in  place  so  there  will  be  a  common  “black 
core”  transport  by  2008.  So  all  data  will  be  encrypted  and  flowing  through  this  black  core  and 
come  out  of  the  black  domain  through  various  gateways,  you'll  see  these  are  across  the  main 
systems  that  are  doing  that  filtering,  and  DISA  might  be  a  good  place  to  build  those,  but  there 
will  be  a  lot  of  activity  in  those  cross  domain  solutions  of  being  able  to  move  data  in  some 
automated  way  between  domains  to  other  agencies  and  communities  of  interest. 


HSDN  Vision  (Composite  from  Multiple  Sources) 


•  Single  converged  backbone  for  the  HLS  Federal 
Communities 

•  Migrate  from  US  SECRET  to  MLS 

—  MLS  Driven  by  1C,  Federal,  State,  Local  and  Private 
—  DoD  U  to  SCI  (caveat  1-n) 

—  DOE  Q  and  L 
—  Local/State/Federal  LES  (1-n) 

—  Private  Industry  Proprietary  (1-n) 

•  Gateways  Between  SIPRNET/GIG/HSDN+  POPs 

•  Gateways  to  State  POPs 

—  Govenor/CISO  policy  control 

•  Title  32,  10  and  50  issues 

•  Collaborative  Enterprise  Services 

—  HLS/DHS/HLD  Decision  Support 

•  Dynamic  Policy  Management 
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In  2012,  the  first  major  collapse  in  the  GIG  [Slide  5]  is  planned  of  bringing  together  the  top 
secret  and  secret  network  into  one  major  backbone  and  I  have  left  the  black  core  as  well  up  there 
that  will  still  be  there  at  that  time  and  there  will  be  ever  more  increasing  complexity  in  the  cross 
domain  solutions  of  what  can  move  across  domains,  with  when  and  how,  controlled  through 
policy  and  gateway  design/implementations. 
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I  won't  spend  long  on  this  but  the  point  but  service  oriented  architectures  [Slide  6]  are  a  crucial 
component  of  being  able  to  have  the  dynamics  needed  to  address  these  information  sharing 
situations  and  to  get  the  services  across  to  users  that  need  the  information  And  you  see  this 
move  everywhere  in  the  DoD,  DHS  and  HLS  communities.  You  also  see  these  types  of  services 
migrating  into  cars,  you  see  it  in  the  public  safety  automation  and  see  the  commercial  approach 
migrating  capabilities  into  the  DoD  through  the  GIG.  Meanwhile  this  movement  is  going  on  in 
both  the  simulation  community  that  was  talked  about  yesterday  by  Andrew  and  in  the  C3  space 
that  is  the  broader  subject  of  this  conference.  We  are  going  too  more  transparency  in  the  future 
about  where  resources  are  coming  from  and  how  they  are  distributed.  And  we  will  end  up 
eventually  with  abstract  web  services  for  efficient  execution  of  tasks  and  we  will  not  need  to 
know  where  the  resources  come  from,  the  system  itself  will  go  find  these  for  you. 

And  this  vision  from  the  GIG  and  DHS  are  starting  down  that  path  of  what  are  these  services, 
how  will  we  bring  together  these  dynamic  configurations  and  dynamic  resources  all  driven  by 
the  policies  that  we  make  [Slide  9].  The  art  of  this  new  effort  is  going  to  be  in  those  policies. 
And,  going  back  to  many  things  that  Dr.  Pohl  talked  about,  if  we  don't  have  intelligent  software, 
this  approach  is  not  going  to  work.  It  has  got  to  be  there,  and  it  has  to  be  very  smart  about  how 
we  obtain  resources,  how  we  combine  them,  how  we  put  together  our  configurations  and  our 
policies  underneath  those  dynamic  resource  constraints  that  we  will  always  have. 

This  is  if  it's  appropriate  down  for  information  access.  For  example  for  the  first  time  we  are 
going  to  be  in  a  situation  where  the  person  with  the  computer  with  the  data  with  the  radio  on  a 
classified  network  is  going  to  be  captured  and  that  person  will  more  than  likely  be  cooperative  on 
that  network,  so  how  do  we  balance  those  problems  of  access  and  security.  So  what  we're 
looking  at  here  is  security  risk  measurement,  what  is  the  risk  of  mission  accomplishment  against 
network/information  risk.  Is  the  person  in  a  place  he  can  be  captured,  is  he  in  any  place  where 
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anybody  can  see  his  screen  with  classified  information,  is  he  is  a  place  where  he  is  safe,  and  it  is 
a  secure  bunker.  All  those  things  go  into  the  risk  equation,  the  question  is  what  is  the  operational 
need,  how  much  data  do  you  need  to  do  your  job. 

An  interesting  example  is  Blueforce  tracking,  if  the  one  guy  that  got  captured  has  assess  to  BFT, 
you  probably  don't  want  to  transmit  to  far  where  all  your  friends  are  around  you.  So  those  are 
the  realities  we  are  going  to  be  facing  and  the  NS  A  task  force  is  addressing  this  directly  and  is 
addressing  that  how  are  we  going  to  do  this  and  how  is  it  going  to  be  implemented  in  the 
network  and  across  the  network  boundaries.  It  goes  down  to  where  is  data  that  going  to  be 
stored,  how  much  of  it,  what's  its  lifespan  at  that  location  how  is  it  encrypted  [Slide  9].  All  of 
those  kinds  of  things  are  addressed  in  what  is  known  as  Risk  Assessment  Demand  Access 
Control  (RAD AC)  illustrated  on  this  slide  [Slide  10].  Lots  of  information  is  expected  to  be 
available  to  weigh  risks  to  information  exposure. 


Slide  10 


Slide  11 


And  it  is  a  very  complex  model  of  how  you  decide  if  you  can  release  it  or  not  to  a  requesting 
user  [Slide  11].  At  least  one  of  the  first  calculations  that  was  done  is  to  make  a  transaction  in  the 
GIG,  that  is  one  IER  transaction,  there  will  be  100  other  transactions,  checking  security,  finding 
the  resources,  doing  compiles  etc...  So  there  is  a  lot  of  work  going  on,  particularly  in  the  task 
force,  trying  to  pin  down  how  big  a  problem  we  are  looking  at  but  this  definitely  goes  into  the 
category  of  hard  problems  to  be  worked. 

But  what  is  true  across  all  communities,  if  we  don't  find  a  way  to  effectively  share  information 
[Slide  12]  in  the  right  time  we  are  out  of  luck,  and  this  is  just  the  ones  out  of  a  defense  science 
force  study  showing  that  across  the  spectrum  of  the  task  and  the  organizations  we  have  that  will 
need  to  solve  the  problem.  We  have  to  solve  it  on  our  warfare  and  we  have  to  solve  it  on  the 
homeland  security  side  and  we  have  to  go  all  the  way  across  a  very  strange  coalition  to  make  it  a 
reality  in  the  counter  terrorism  war. 
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Information  Sharing-  The  Critical  Enabler 
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This  slide  [Slide  13]  illustrates  a  joint  networking  approach  with  a  few  other  services  available 
to  the  aggregated  system.  The  concept  is  that  there  is  going  to  be  one  big  policy  driven  system 
with  lots  of  spheres  of  influence.  All  these  policies  are  going  to  be  made,  their  presence  in 
networks  from  TC,  the  air,  homeland  secure  data  net,  all  the  way  down  to  the  state  levels  and 
intelligence  community  with  everybody  guarding  their  data  and  access  to  their  data  controlled 
through  policy  driven  systems 


I  am  going  to  go  through  these  Markle  Foundation  slides  quickly,  you  can  read  them  in  the 
proceedings,  or  if  you  want  to  go  up  to  www.markle.org  [Slides  14-19].  Once  again  a  very 
interesting  task  force  sitting  down  to  decide  what  are  the  information  sharing  requirements  and 
what  are  the  security  and  privacy  concerns  that  we  need  to  look  at  from  a  Homeland  Security 
viewpoint  of  the  situation.  This  viewpoint  is  from  a  mixture  of  technologists  and  government, 
and  all  the  way  down  to  the  governors  who  are  the  people  really  responsible  for  our  safety  in  this 
counter  terrorism  war  within  our  50  states. 
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Defining  the  future 

Illustration  No.  1 :  Some  Characteristics  of  a  Next-Gei 
Homeland  Security  Information  Network 


•1.  Empower  Local  Participants 

•Local  participants  must  be  empowered  to  contribute,  access,  use,  and 
analyze  data.  At  the  same  time  they  must  be  allowed  to  identify,  access, 
communicate  with,  and  assemble  other  participants  in  both  the  public  and 
private  sectors. 

•Expert  groups  must  be  allowed  to  form  at  the  edge  of  the  network.  Data 
should  be  maintained  and  rule  sets  should  be  developed  and  implemented 
by  and  among  local  participants.  Each  should  be  allowed  to  undertake  as 
much  work  as  they  are  capable  of  doing. 

•Push  computing  requirements  away  from  the  center  to  utilize  excess 
capabilities  at  the  “edge”  of  a  network,  allowing  mini-centers  to  develop 
around  local  expertise,  which  can  then  be  accessible  to  other  network 
participants. 
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lustration  "W  oT'l :  Sorne  Characteristicso^mexTGefi 
Homeland  Security  Information  Network  (Continued) 

•3.  Create  Safeguards  and  Guidelines  to  Protect  Civil  Liberties 

•National  security  systems  should  raise  concerns  about  privacy,  civil 
liberties,  and  due  process.  To  protect  against  abuse  in  how  information  can 
be  used,  accessed,  or  shared,  participants  need  clear  guidelines  based  on 
our  laws  and  social  values. 

•The  DHS  should  take  the  lead  in  creating  robust  permissioning  structures 
and  audit  trails  that  will  help  enforce  appropriate  guidelines.  These  critical 
elements  could  employ  a  wide  variety  of  authentication,  certification, 
verification,  and  encryption  technologies.  Role-based  permissions  can  be 
implemented  and  verified  through  the  use  of  certificates,  for  example,  while 
encryption  can  be  used  to  protect  communications  and  data  transfers.  A 
robust  Public  Key  Infrastructure  (PKI)  or  other  authentication  system  within 
the  network,  driven  by  DHS  at  the  core,  may  turn  out  to  be  crucial.  Auditing 
tools  that  track  how,  when,  and  by  whom  information  is  accessed  or  used 
ensure  accountability  for  network  users.  These  two 
safeguards— permissioning  and  auditing  —will  free  participants  to  take 
initiatives  within  the  parameters  of  our  country’s  legal,  cultural,  and  societal 
norms. 
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llustration  No.  1 :  some  Characteristics  of  a  Nert 
Generation  Homeland  Security  Information  Network 


(Continued) 

•5.  Design  a  Robust  System 

•The  network  must  be  designed  and  deployed  to  withstand  extreme  stress  or  crisis. 
Points  of  failure  must  be  identified  and  minimized,  just  as  points  of  access  must  be 
maximized  to  encourage  widespread  usage  among  qualified  participants.  Systems 
must  be  designed  from  the  “bottom-up,”  in  order  to  facilitate  dynamic  and  rapid 
evolution  in  response  to  changing  needs.  Redundancy,  interoperability,  and  open 
standards  are  all  elements  that  constitute  robust  networks.  Ensuring  that  the 
network  can  continue  to  operate  in  the  event  of  the  loss  of  a  portion  of  the  network 
is  crucial— a  so-called  “gracefal  collapse”will  prevent  catastrophic  failures.  The 
ability  to  find,  access,  and  use  data  demands  common  or  interoperable  data 
structures  and  schemas;  the  industry  standard,  XML,  is  an  obvious  option  that  can 
facilitate  access  to  legacy  data  as  well  as  provide  utilitarian  structures  for  to-be- 
collected  data. Meta-data,  watermarking,  and  indexing  tools  can  facilitate  data 
interoperability,  storage,  and  retrieval.  Communications  standards  —  TCP/IP,  HTTP, 
and  other  common  Internet  technologies— can  help  simplify  and  ensure  that 
connectedness  is  maintained  throughout  the  network.  Keeping  computation  and 
storage  at  the  edge  of  the  network  also  allows  for  redundancy  and  capacity 
building. 
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(Continued) 

•10.  Create  a  Connected  Culture 

•A  cooperative,  collaborative  culture  is  required  for  the  success  of  dynamic 
connectedness.  Just  as  individuals  are  empowered  through  next- 
generation  network  designs,  participants  must  also  support  the  successful 
exploitation  of  these  technologies  through  positive  reinforcement,  peer 
pressure,  and  accountability  as  well  as  repudiation  of  users  who  abuse  the 
system.  Feedback  systems  that  reward  valuable  contributors  will  help 
establish  credibility  both  for  individual  participants  and  the  network  as  a 
whole.  Reliable,  robust,  and  secure  communications  will  encourage 
interactivity.  Appropriate  and  verifiable  permissioning  systems  will  support 
the  development  of  trustworthy  relationships.  Networks  that  drive  both 
electronic  and  traditional  collaboration  can  create  a  mutually  reinforcing 
environment  for  all  involved. 
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I  am  going  to  go  through  these  slides  quickly  but  you  will  see  things  very  similar  things  to  the 
GIG  in  this  slide  set,  this  is  the  concept  of  power  to  the  edge,  of  course  they  have  likely  never 
heard  of  that  term  on  the  homeland  security  side  of  the  discussion  but  it  is  essentially  what  they 
are  saying  here. 


A  little  bit  different  take  on  this,  this  network  is  going  to  have  our  private  data  in  it  so  how  is  it 
going  to  be  protected,  how  are  we  going  to  put  permissioning  structures  in  place  to  guarantee 
that  our  privacy  will  be  enabled  and  protected  and  similar  role  base  permissions  for  getting  to 
that  data  so  you  see  very  similar  things  to  what  we  see  in  the  GIG  for  enabling  technologies. 

And  essentially  this  is  what  they  are  looking  for  GIG  and  HLS  sides  of  the  problem.  We  are 
both  looking  for  a  dynamic  and  connective  set  of  technologies  that  allow  all  the  people  that  need 
to  solve  a  particular  problem  set  onto  a  “network”  at  the  right  time,  but  at  the  same  time  ensuring 
that  the  network  is  secure  and  the  authorized  policy  permissions  are  actually  enforced. 


One  can  ask  what  is  the  scale  and  the  time  of  all  of  this  technology  implementation  and  that  is 
still  to  be  determined,  but  you  do  see  people  moving  out  the  everywhere  and  this  may  actually 
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accelerate  some  of  the  things  we  are  talking  about  here.  There  are  a  lot  of  people  on  the  many 
sides  pushing  pretty  hard  to  get  these  information  sharing  technologies  in  place. 


This  is  the  simple  picture  [Slide  20]  of  a  future  information  sharing  environment  and  how  it 
might  come  about.  I  think  I  put  the  GIG  AI  requirements  in  context  and  then  I  compared  it  to 
HSDN  you  have  a  vision  of  this  give  and  take  on  both  sides  and  I  should  say  the  homeland 
security  data  that  I  am  talking  about  here  is  very  large  compared  to  typical  DoD  warfighting  data 
sets  as  it  is  everything  that  comes  out  of  DHS/HLS  lumped  into  one  set  of  data  at  this  point. 


Defining  the  future 


H 


The  call  to  action 


“This  is  government  acting  in  new  ways,  to  face  new  threats,”  the  most 
recent  Markle  report  explains.“And  while  such  change  is  necessary,  it 
must  be 

accomplished  while  engendering  the  people’s  trust  that  privacy  and 
other  civil 

liberties  are  being  protected,  that  businesses  are  not  being  unduly 
burdened 

with  requests  for  extraneous  or  useless  information,  that  taxpayer 
money  is 

being  well  spent,  and  that,  ultimately,  the  network  will  be  effective  in 
protecting  our  security  .’’The  authors  add:  “Leadership  is  emerging  from 
all  levels  of  government  and  from  many  places  in  the  private 
sector.What  is  needed  now  is  a  plan  to  accelerate  these  efforts,  and 
public  debate  and  consensus  on  the  goals.”  91 1  Commission 
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It  is  actually  more  complicated  than  that  as  this  slide  [Slide  21]  illustrates.  This  is  from  the  DSB 
Homeland  Security  Report  again,  looking  at  bringing  together  homeland  defense  its  power 
projection,  the  homeland  security  piece,  looking  at  DoD's  dependent  on  the  infrastructure  which 
they  live  within,  75%  of  all  the  enabling  capability  for  our  bases  here  in  the  US  are  actually  in 
the  private  sector,  so  that's  the  best  that's  generally  the  weakest  link  if  you  want  to  go  after  DoD 
warfighting  capabilities.  But  this  system  we  are  discussing  it  what  brings  them  all  together. 
These  are  a  lot  of  different  communities  of  interest  and  sorting  all  this  policy  and  technology  out 
is  going  to  take  some  time  but  it  will  happen  if  we  are  to  increase  our  collective  security. 

What  this  comes  down  to  is  that  we  are  looking  at  right  now  is  migrating  from  an  enclave 
security  model  down  to  where  information  has  to  be  encrypted  on  your  device  to  maintain  end- 
to-end  security.  If  that  device  is  actually  going  to  be  captured  you  really  don't  want  someone 
running  around  with  all  the  everyone  else’s  and  your  data  on  it.  And  then  other  issues  such  as 
how  do  you  protect  the  jeopardized  personnel,  the  information,  continue  your  mission  and 
protect  the  network.  How  do  the  network  security  folks  realize  when  capture  and/or  potential 
capture  events  take  place  in  this  mobile  networks  of  networks?  The  larger  problem  in  mobile 
world  now  is  how  do  we  get  identity,  authorizations,  behavior  and  keying  material  for  all  that 
data/information  to  the  right  place  at  the  right  time.  Some  of  this  is  started  already  if  you  look  at 
your  credit  cards  and  you  go  around  different  places  they  now  have  the  behavior  models  up  and 
running.  For  example  we  the  credit  card  authorization  system  realizes  that  you  weren't  there 
(typically  overseas)  last  week  and  why  are  you  buying  it  there  now,  so  we'll  hold  your  card 
authorization  for  you  until  you  call  us  and  tell  us  you're  the  right  person.  So  this  is  a  beginning 
of  the  operational  behavior  modeling  for  the  service  access.  And  there  is  lots  of  work  going  on 
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at  the  policy  standards  meetings  these  days  regarding  similar  technologies  for  network  access. 
These  rules  are  envisioned  to  be  driven  by  policy  similar  to  what  IBM  talked  about  yesterday. 
Extreme  activity  is  seen  in  the  whole  mobile  community  of  how  are  we  going  to  move  these 
authentications,  authorizations,  and  accounting  information  around  the  networking  community. 
From  the  DoD  side  the  network  you  are  connecting  to  may  not  belong  to  your  service  and/or 
may  not  even  belong  to  your  department.  How  are  they  going  to  get  to  know  who  you  are  what 
you  are,  what  you  are  authorized  to  do  so  on  and  so  forth.  Decisions  are  much  more  complex 
when  we  are  fighting  the  counter  terrorism  war  at  home.  Issues  such  as  to  when  we  intercept  an 
inbound  ballistic  missile,  where  exactly  are  we  going  to  drop  it  and  in  how  many  parts,  all 
serious  issues  that  involve  very  diverse  communities  to  optimize  the  solution  in  the  time 
available. 

But  I  will  walk  you  through  the  MDA  example  here  very  quickly.  There  are  some  definite 
bottom  line  changes  in  the  way  security  is  done  and  the  way  networks  will  be  architected  in  the 
future,  how  the  data  will  be  protected,  how  you  get  to  that  data,  how  you  authenticate  yourself, 
all  of  those  kinds  of  things  are  going  to  be  fundamentally  changed  from  what  you  know  today  to 
meet  this  kind  of  mission.  In  this  culture  this  is  expected  to  be  a  broad  movement  over  a 
considerable  time  frame.  You've  got  the  “coalition”  illustrated  here  on  the  DoD  side  and  then 
the  Homeland  Security  “coalition”  illustrated  there  over  on  the  other  side  extending  all  the  way 
from  the  president  right  on  down  to  the  local  citizen  response  team  working  homeland  security 
activities.  A  lot  of  very  different  data  and  networks  will  have  to  come  together  to  optimally 
address  this  type  of  homeland  security  and  homeland  defense  issue  in  some  optimal  way.  [Slide 
22] 
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Implications  for  the  need  to  share 


•  Enclave  migrating  to  host/edge  security 

—  HAIPE  to  IPsec  (transport) 

—  CBIS  (at  rest) 

—  Inherent  Multilevel  (MLS)  Security 

•  Personnel,  hosts  and  network  elements  will  be  captured 
intact 

—  How  do  we  best  protect  the  personnel,  information,  mission  and 
network? 

•  Global  identity,  authorizations,  behavior,  keying  material 

•  Temporal  security  policies 

—  Access 

—  Dynamic  cross  domain  guards 

•  Lots  of  detail  to  be  worked  out  in  the  Policy  and  Mobile 
IPv6  DoD/IC  and  DHS/HLS  communities 

•  Integration  with  Decision  Support  Systems 

—  What  are  the  new  decisions? 
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Is  all  this  going  to  happen  and  actually  come  to  fruition?  We'll  wait  and  see.  [Slide  23]  There 
are  significant  challenges  in  that  there  is  significant  coordination  activity  indicated  from  a  lot  of 
people  who  don't  typically  work  together.  The  whole  discussion  going  on  between  the 
intelligence  community,  DoD,  homeland  security  and  how  this  plays  out  we'll  wait  and  see,  but 
there  is  a  lot  of  movement  going  on  in  the  various  communities  so  it  should  be  an  interesting 
time  as  the  hard  issues  for  homeland  security  and  defense  are  being  addressed  at  a  fundamental 
level. 
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Abstract 

A  key  goal  of  information-centric  software  is  to  achieve  interoperability  among  decision- 
support  systems.  Architectures  for  supporting  this  vision  typically  involve  a  set  of 
collaborating  agents  along  with  a  common  ontology  for  sharing  information.  This  will 
require  integrating  legacy  data-centric  systems  that  provide  access  to  relevant  data 
sources.  We  address  the  problem  of  integrating  such  systems  when  these  sources  are  in 
text  format.  Thus,  our  challenge  is  to  identify  the  conceptual  content  of  text  sources  to 
facilitate  its  sharing  and  integration.  Natural  language  processing  (NLP)  technologies  are 
the  primary  means  for  identifying  and  extracting  concepts  from  text.  However,  existing 
NLP  techniques  that  use  traditional  sense  enumerative  linguistic  ontologies  are  severely 
limited  for  supporting  this  task,  and  suggest  that  a  form  of  generative  linguistic 
ontologies  be  used  instead.  We  describe  FACIT,  our  knowledge  extraction  framework, 
and  highlight  its  use  of  generative  sublanguage  ontologies,  an  extension  of  generative 
lexicons,  to  support  knowledge  extraction.  We  also  summarize  our  work  to  date  on  this 
framework  and  describe  future  work  needs  and  interests. 

Keywords:  Knowledge  extraction,  text  documents,  generative  linguistic  ontologies 

1 .  Introduction 

The  US  armed  services  are  developing  net-centric  warfare  (NCW)  concepts  and  systems  for 
achieving  their  information  superiority  goals  (Alberts  et  al.  1999).  These  goals  include  the  ability 
to  collect,  process,  and  share  information  while  preventing  adversaries  from  doing  likewise.  The 
potential  impacts  on  warfare  concepts  and  mission  execution  are  enormous,  and  will 
significantly  change  the  way  warfighters  operate. 

Decision  support  systems  play  a  pivotal  role  in  the  design  and  implementation  of  NCW  goals.  In 
particular,  systems  that  implement  teams  of  software  agents  are  expected  to  increasingly  support 
decision  makers  with  the  ability  to  quickly  process  and  fuse  sensor  information,  construct 
common  operational  pictures  for  situation  assessment,  provide  an  overview  of  the  decision 
space,  and  convey  an  understanding  of  the  ramifications  of  making  these  decisions. 

These  goals  require  that  agents  be  interoperable  and,  in  particular,  be  able  to  access  and  share 
information  towards  achieving  their  respective  decision  aiding  tasks.  However,  achieving 
interoperability  is  difficult,  and  its  lack  thereof  is  a  primary  information  systems  problem  (Pohl 
2001).  Pohl  explains  that  obstacles  to  interoperability  can  be  overcome  by  embedding  the 
integrated  system  in  software  that  has  some  understanding  of  the  data  being  processed,  and  this 
requires  addressing  issues  concerning  its  representation. 
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We  address  a  subset  of  the  interoperability  challenge  that  focuses  on  sharing  text  documents.  We 
describe  a  technique  for  representing  term  meanings  {generative  sublanguage  ontologies )  for 
identifying  and  extracting  concepts  from  text  documents,  a  framework  that  uses  it  for  document 
interpretation,  and  our  partial  implementation  of  this  framework.  We  exemplify  our  approach 
and  discuss  related  and  future  work. 

2rl .  Knowledge  Extraction  for  Decision  Support 

Decision  support  systems  are  designed  to  assist  their  users  with  situation  assessment  and  perform 
decision  analysis.  These  systems  are  typically  interactive  and  allow  the  user  to  control  their 
decision-making.  A  primary  characteristic  of  decision  support  systems  is  that  they  must  be 
provided  with  a  domain  description  in  which  decisions  are  made  and  the  access  to  pertinent 
heterogeneous  data  sources.  Information  from  these  sources  must  be  extracted  and  integrated  to 
assist  with  situation  assessment  and  decision  analysis.  Data  can  be  in  many  modalities  (e.g., 
speech,  imagery,  video,  text). 

We  focus  on  issues  pertaining  to  extracting  information  from  text  sources  that  are  semi- 
structured.  Examples  of  such  sources  in  NCW  include  OPORDS  (operations  orders),  doctrine, 
TTPs  (Tactics,  Techniques,  and  Procedures),  AARs  (After  Action  Reports)  from  previous 
missions  and  exercises,  and  lessons  learned.  Our  motivating  task  concerns  the  sharing  and 
integrating  of  lessons  learned  documents  in  decision  support  systems.  We  describe  this  task  in 
Section  2.1  and  present  our  approach  to  solve  this  problem  in  Section  2.2. 

2ril .  1  Motivating  task 

HICAP  is  a  mixed- initiative  plan  authoring  tool  suite  that  speeds  up  the  process  of  deliberatively 
planning  a  course  of  action  (Munoz-Avila  et  al.  1999).  HICAP  supports  its  users  with  their 
planning  decisions.  In  particular,  using  a  hierarchical  planning  representation,  it  helps  the  users 
decide  how  to  decompose  a  given  task  via  a  mixed-initiative  situation  elicitation  module  that 
provides  access  to  previous  <situation,  decision>  experiences.  It  also  contains  an  automated  plan 
decomposition  module  that  can  accelerate  plan  authoring  at  nodes  where  the  subtasks  can  be 
automatically  selected. 

We  also  integrated  HICAP  with  ALDS,  a  case  retrieval  tool  that  proactively  identifies 
relevantNavy  Lessons  Learned  (NLLS  2004)  and  brings  them  to  a  user’s  attention  when  they 
apply  to  the  currentplanning  situation  (Aha  et  al.  2001;  Weber  and  Aha  2002a).  While  HICAP 
operates,  ALDS  silently  monitors  the  situation  being  described  by  the  user  and  compares  it  with 
the  stored  lessons,  which  are  represented  as  <task,  situation,  decision>  cases.  Those  lessons 
whose  task  and  situation  sufficiently  match  the  current  planning  task  and  its  situations  are 
brought  to  the  user’s  attention.  Next,  the  user  can  decide  whether  to  automatically  apply  a 
suitable  adaptation  of  the  retrieved  lesson’s  decision  (e.g.,  a  plan  decomposition,  a  resource 
substitution)  in  the  current  planning  context. 

Creating  a  case  library  for  ALDS  requires  a  significant  knowledge  engineering  effort.  In 
particular,  this  requires  a  domain  expert  to  identify  a  lesson’s  task,  specify  the  situations  that 
must  be  met  for  the  lesson  to  apply,  and  provide  the  lesson’s  recommendation  framed  as  a 
planning  decision.  Manually  creating  such  lessons  is  a  tedious  and  potentially  error  prone 
process.  Two  approaches  could  be  used  for  lesson  acquisition,  first,  a  lesson  elicitation  tool 
could  be  developed  that  guides  users  through  the  process  of  collecting  lesson  content  in  the 
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Figure  1:  The  FACIT  knowledge  extraction  framework. 


computable  representation  used  by  ALDS.  We  developed  the  Lesson  Elicitation  Tool  (LET)  to 
meet  this  need  (Weber  and  Aha  2002b).  However,  this  approach  ignores  the  huge  body  of 
existing  lessons  learned.  The  computable  representation  for  existing/archived  lessons  must  be 
derived  using  a  knowledge  extraction  process.  We  describe  this  second  approach  in  Section  2.2. 

2t2/.  1  The  FACIT  knowledge  extraction  framework 

We  created  a  framework  for  extracting  case  indices  from  archived  lessons.  Our  framework, 
named  FACIT  (Feature  Acquisition  and  Case  Indexing  from  Text),  is  displayed  in  Figure  1. 
FACIT  updates  the  semantic  lexicon  and  uses  it  for  syntactic  and  semantic  interpretation  to 
create  a  logical  form,  which  is  a  set  of  sentences  represented  in  a  predicate  argument  structure.  It 
then  extracts  features  from  this  logical  form  to  index  cases.  This  process  involves  the  seven  steps 
shown  in  the  Figure  1 . 

FACIT  has  several  novel  characteristics.  First,  it  operates  on  semi-structured  text  documents, 
which  distinguishes  it  from  other  frameworks  that  instead  perform  concept  extraction  under 
strong  assumptions  on  text  structure  and  content.  Second,  it  uses  a  semantic  lexicon  inspired  by  a 
generative  approach  (Pustejovsky  1995),  which  permits  it  to  robustly  identify  concepts.  Third,  it 
implements  a  knowledge  extraction  process  (Cowie  and  Fehnert  1996);  it  is  not  told  a  priori 
which  features  should  be  used  as  case  indices;  instead  it  must  depend  on  a  subject  matter  expert 
to  interactively  identify  useful  features  in  a  few  sample  sentences.  Fourth,  it  represents  case 
indices  in  a  set  of  feature  subsumption  taxonomies  (Gupta  2001). 

We  describe  FACIT’s  steps  in  the  rest  of  this  section.  We  then  summarize  FACIT’s 
implementation  status  in  Section  3,  and  describe  related  and  future  work  in  Sections  4  and  5, 
respectively. 
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Step  U  Lexicon  engineering  (with  generative  sublanguage  ontologies )_ 


As  shown  in  Figure  1,  semantic  interpretation  and  feature  organization  depend  on  the  availability 
of  a  semantic  lexicon,  also  known  as  a  linguistic  ontology.  These  ontologies  encode  a  domain’s 
terms  and  their  corresponding  conceptual  representations.  This  permits  linguistic  ontologies  to 
look  up  a  given  term’s  potential  senses  ( concepts )  and  use  a  disambiguation  technique  to  select 
the  most  applicable  sense  among  them.  However,  domain-independent  linguistic  ontologies  (e.g., 
WordNet  (Felbaum  1998);  SENSUS  (Knight  and  Luk  1994))  have  poor  coverage  for  domain- 
specific  text  applications.  For  example,  WordNet  covers  only  25.6%  of  the  terms  in  the  naval 
training  exercises  domain  that  we  extracted  from  a  subset  of  Navy  Lessons  Learned  (Gupta  et  al. 
2002).  WordNet’s  coverage  of  senses  is  likely  to  be  even  lower  because  it  lacks  domain  specific 
senses  for  known  terms.  Consequently,  lexical  resources  must  be  updated  to  include  domain 
specific  terms  and  their  senses.  Thus,  issues  of  concern  include  the  choice  of  lexical 
representation  and  the  effort  required  to  update  it. 

Linguistic  ontologies  can  be  categorized  as  either  sense  enumerative  (e.g.,  WordNet,  SENSUS) 
or  generative  (Pustejovsky  1995).  Table  1  compares  these  two  types  of  ontologies.  Sense 
enumerative  variants,  which  require  listing  every  sense  of  a  term  or  phrase  in  the  lexicon,  have 
weak  lexical  semantics  (i.e.,  they  incorporate  only  a  few  impoverished  relation  types  between 
concepts),  weak  compositionality  (i.e.,  they  cannot  derive  unlisted  meanings  of  a  term),  and  large 
sense  ambiguities.  Thus,  the  effort  to  update  them  increases  linearly  with  the  number  of 
unknown  senses  and  terms.  In  contrast,  generative  linguistic  ontologies  include  rich,  well- 
principled  semantics  and  do  not  require  explicitly  listing  all  potential  senses  of  a  term.  Instead,  a 
small  set  of  powerful  operators  generates  them  on  demand  based  on  their  context  of  use, 
substantially  reducing  the  sense  disambiguation  effort  as  a  consequence.  Generative  linguistic 
ontologies  support  strong  compositionality  and  can  derive  senses  of  previously  unseen 
combination  of  terms.  Finally,  the  effort  required  to  update  generative  linguistic  ontologies  is 
sub-linear  and  comparatively  marginal. 

A  Generative  Lexicon  (GL)  (Pustejovsky  1995)  is  a  type  of  generative  linguistic  ontology  that 
was  developed  by  computational  linguists  to  address  some  of  the  problems  inherent  with  sense 


Table  1:  Distinguishing  sense  enumerative  from  generative  linguistic  ontologies. 


Characteristics 

Sense  Enumerative 

Generative 

Number  of  entries  (size) 

Large:  one  concept  per 
sense  of  a  term 

Compact:  One  concept  per  set 
of  related  meanings  of  a  term 

Interpretation  robustness 

Brittle;  fails  if  required 
sends  is  not  lexicalized 

Robust;  generates 
unanticipated  senses,  and 
degrades  gracefully 

Compositionality 

Low 

High 

Disambiguation  support 

Low 

High;  part  of  sense  selection 
and  generation 

Maintenance 

High 

Low 

Available  implementations 

Many 

None? 

enumerative  linguistic  ontologies.  Briefly,  a  GL  attempts  to  represent  multiple  related  meanings 
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of  a  term  (i.e.,  systematic  polysemy)  using  a 
well  principled  conceptual  structure.  This 
conceptual  structure  has  four  primary 
components: 

1.  Arguments:  These  are  a  concept’s 
logical  arguments. 

Sri.  Qualia :  These  represent  a  concept’s 
defining  attributes  (e.g.,  constituent 
parts,  purpose). 

Trl.  Events'.  These  define  a  concept’s 
event  structure. 

4rl.  Inheritance :  These  permit  a  concept  to 
inherit  the  first  three  elements  from  its 
parent. 


M  U  LTI PASS-C-5500  <Entity> 


terms 
type  of 

attributes 

constituents 

behaviors 
creative  events 


Multipass-C-5500/n,  unit/n 


PRINTING  INSTR 


!SIZE(this,  unspecified), 
!COLOR(this.  unspecified). 


PART (this,  SHEETFEEDER),— 
PART (this,  OP_PANEL), 

PART (this,  POWER  CORD),  ... 


!PRINT_ACT(HUMAN, INFO, this), 
MOVE ACT(HUMAN,INFO,...) 


MAKE ACT(CANON INC,  this) 


SHEETFEEDER  <Entity> 

terms 
type  of 

attributes 

constituents  |  PART(this,  PAPER_GUIDE),  ...  | 
behaviors  FEED_ACT(HUMAN,  PAPER,  this,  MULTlPASS-C-5500) 


sheet  feeder/n,  ADF/n 
FEEDINGINSTR 
!SIZE(this,  unspecified), 
!COLOR(this.  unspecified). 


In  addition,  GLs  generate  and  select  the  Vcreat,Ve ei/ente  ES.act(canonjnc,  mis)  | 
meaning  of  a  term  in  its  context  (i.e.,  other  Figure  2:  Two  GSO-represented  concepts, 

terms  related  to  a  term  by  syntactic  structure), 

when  syntactic  and  semantic  constraints  fail,  by  using  generative  operators  such  as  type  coercion 
and  co-composition.  These  provide  GL  with  a  powerful  mechanism  for  sense  generation  and 
disambiguation. 


While  theoretically  useful,  our  analysis  has  revealed  that  this  representation  requires  several 
practical  extensions,  which  we  describe  in  (Gupta  and  Aha  2003).  We  call  our  extended 
representation  a  Generative  Sublanguage  Ontology  (GSO),  which  uses  predicate  argument 
structures  in  a  multiple-inheritance,  object-oriented  framework  with  argument  bindings.  GSOs 
are  distributed,  accommodate  subjectivity  and  redundancy,  and  are  minimal.  In  contrast  with 
GLs,  GSOs  support  morphologic  operations  (e.g.,  inflection,  derivation),  distinguish  four 
primitive  concept  types  (i.e.,  entity,  value,  state,  and  event)  to  constrain  and  simplify  concept 
representation,  and  include  an  extended  representation  for  world  knowledge  (pragmatics)  at 
appropriate  abstraction  levels.  These  features  contribute  to  improving  the  accuracy  and 
robustness  of  text  interpretation  and  simplify  lexicon  engineering  tasks  (Gupta  and  Aha  2003). 


Figure  2  displays  two  GSO-represented  concepts  for  a  Canon  Multipass  C-5500  printer  and  its 
sheetfeeder.  Both  concepts  are  represented  as  entities,  and  are  related  in  that  the  sheetfeeder  is  a 
part  of  the  printer.  Shown  are  terms  for  naming  these  concepts,  their  type,  some  common 
inherited  attributes,  constituents,  behaviors  that  involve  them,  and  the  event  that  created  them. 


In  summary,  GSOs  can  help  to  derive  canonical  concept  representations  of  text  sources,  thus 
facilitating  interoperability.  Furthermore,  they  make  interoperability  feasible  by  reducing  the 
need  to  update  lexicons  in  dynamic  domains,  in  part  by  supporting  a  generative  sense-selection 
process  in  which  they  can  identify  a  novel  phrase’s  sense  without  having  previously  encountered 
it.  Most  importantly,  they  can  be  used  to  help  derive  a  logical  form  of  the  text,  which  we  discuss 
below. 
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Step  2_j  Syntactic  parsing;. 


Syntactic  parse  tree 


Using  a  suitable  grammar  and  a  GSO 
for  its  lexicon,  this  step’s  goal  is  to 
assign  part-of-speech  and  identify 
sentence  structure  for  the  given 
document.  We  represent  sentence 
structure  with  a  hierarchy  of  syntactic 
relationship  among  its  terms.  Syntactic 
structures  are  generated  by  syntactic 
parsers.  They  are  categorized  as  either 
shallow  or  deep.  The  former  use 
statistical,  memory-based  (e.g.,  Zavrel 
and  Daelemans  1999),  and/or  data- 
based  techniques  to  efficiently  return 
one  or  a  few  top  ranked  parses,  but  they 
return  only  constituent  phrases  and  a 
partial  syntactic  structure.  Using 
shallow  parsing  is  problematic  because 
the  likelihood  of  finding  a  valid  parse  can  be  unacceptably  low.  Also,  shallow  parsing  shifts  and 
increases  the  burden  of  knowledge  engineering  to  the  development  of  information  extraction  (IE) 
patterns,  which  provide  limited  domain  knowledge  and  coverage.  In  contrast,  deep  parsers  search 
for  and  enumerate  all  potential  parses.  However,  this  approach  can  generate  numerous  parses, 
thus  resulting  in  considerable  sentence  structure  ambiguity  that  must  be  resolved.  Although 
generating  all  parses  can  be  computationally  expensive,  this  must  be  done  to  find  a  valid  parse. 
For  this  reason,  and  because  we  apply  FACIT  in  an  off-line  process,  we  use  a  deep  parsing 
approach. 

Our  domain  analysis  revealed  that  military  lessons  learned  text  poses  particular  challenges  with 
their  numerous  acronyms,  abbreviations,  and  morphological  variations  of  terms.  Thus,  FACIT 
performs  acronym  (and  abbreviation)  extraction  and  baseform  derivation  of  given  terms.  We 
discuss  these  briefly  in  Section  3. 

Step  3:  Semantic  interpretation: 

Semantic  interpretation  transforms  the  syntactic  parse  into  a  logical  form.  Figure  3  displays  the 
logical  form  for  the  sentence  Data  from  computer  is  not  printed.  It  eliminates  syntactic  variance 
(i.e.,  sentences  with  different  grammatical  structure  but  with  the  same  meaning)  by  reducing 
them  to  the  same  logical  form.  For  example,  the  following  different  sentences  can  be  reduced  to 
the  logical  form  shown  in  Figure  3: 

-  Data  sent  from  the  printer  to  the  computer  is  not  printed 

-  Data  is  not  printed  by  the  printer 

-  Multipass  is  not  printing  data  from  the  computer 


s 


& 


Corresponding  logical  form 


INSTANCE_OF(DATA,data_1)  AND 
INSTANCE_OF(COMP_INSTR,computer_1 )  AND 
NOT(PRINTED(HUMAN,data_1  ,PRINTING_INST))  AND 
NATIVE_OF(computer_1  ,data_1 ) 

Figure  3:  A  syntactic  parse  and  its  corresponding  logical  form. 
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Taxonomic  CCBR  System 


User  Interactions 


Figure  4:  The  Taxonomic  Conversational  Case-Based  Reasoning  methodology. 

Translation  of  text  to  its  logical  form  permits  the  application  of  predicate  calculus  operations, 
thereby  enabling  the  types  of  symbolic  reasoning  needed  for  FACIT’s  feature  extraction  and 
feature  organization  steps. 

FACIT  creates  a  logical  form  from  the  syntactic  parse  using  a  three-step  process.  First,  using  the 
GSO  it  retrieves  concepts  corresponding  to  senses  for  the  terms  in  the  parse.  This  makes  use  of  a 
GSO’s  representation  for  predicate  argument  representations.  Second,  it  resolves  semantic 
ambiguity  (i.e.,  when  multiple  concepts  are  retrieved)  using  a  heuristic  approach.  For  example,  in 
the  example  shown  in  Figure  3,  the  term  from(p)  may  have  multiple  meanings,  including  both 
OCCU RELOCATED  and  NATIVE  OF.  We  assume  that  the  latter  meaning  is  chosen  according 
to  a  heuristic  rule.  In  its  third  and  final  step,  FACIT  resolves  syntactic  ambiguity  by  selecting  the 
parse(s)  with  maximal  predicate  argument  bindings. 

Step  4±  Feature  extraction: 

We  consider  feature  as  a  means  to  describe  a  situation.  Our  approach  will  involve  obtaining 
training  data  by  asking  a  subject  matter  expert  to  annotate  sample  sentences  as  features  or  non¬ 
features.  FACIT  will  use  these  annotations  to  induce  a  classifier,  where  features  are  represented 
in  a  logical  form.  We  will  select  an  appropriate  algorithm  for  inducing  classifiers  by  analyzing 
the  learning  task,  and  will  use  the  trained  classifier  to  extract  features  from  all  the  text. 

We  next  define  our  case  representation  prior  to  defining  the  feature  organization  and  case 
indexing  assignment  steps  (i.e.,  Steps  5  and  6)  that  target  it. 

Step  7:  Conversational  taxonomic  case,  retrieval'. 

We  focus  on  a  stand-alone  lesson  retrieval  capability,  and  discuss  its  integration  with  other 
decision  support  tools  in  Section  5. 

Gupta  (2001)  introduced  a  taxonomic  extension  of  the  conversational  case-based  reasoning 
(CCBR)  methodology,  which  conducts  an  incremental  query  elicitation  “conversation”  with  a 
user  to  help  retrieve  relevant  case(s).  For  our  lesson  retrieval  application,  these  queries  can  be 
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matched  with  lesson  case  situations.  CCBR  systems  represent  cases  as  <problem,  solution> 
pairs,  where  problems  are  represented  as  a  set  of  <question,  answer>  pairs,  or  features. 
Taxonomic  CCBR  organizes  features  into  a  set  of  taxonomies,  where: 

-  each  feature  appears  in  exactly  one  taxonomy, 

-  parent  nodes  subsume  their  children,  in  that  a  parent’s  feature  appears  in  a  superset  of  the 
cases  in  which  its  childrens’  features  appear,  and 

-  the  intersection  among  two  siblings’  cases  is  empty. 

Finally,  the  only  features  that  are  used  to  index  cases  are  the  leaves,  and  each  index  for  a  case 
must  appear  in  a  different  taxonomy.  Gupta  et  al.  (2002)  reported  that  Taxonomic  CCBR 
outperforms  the  standard  CCBR  approach  across  several  performance  variables. 

Our  Taxonomic  Case  Retrieval  System  (TCRS)  implements  this  process,  which  is  shown  in 
Figure  4.  Users  begin  a  conversation  by:  (1)  entering  a  problem  description  (i.e.,  a  query)  in  free 
text.  The  system  responds  by  identifying  which,  if  any,  of  the  known  features  are  included  in  the 
textual  description.  This  in  turn  identifies  the  taxonomies  that  include  the  identified  features. 
These  taxonomies  contribute  a  set  of  questions  that  can  be  asked  for  traversing  down  the 
taxonomies  by  one  level.  TCRS  selects,  ranks,  and  displays  these  questions  to  the  user.  (2)  The 
user  can  answer  any  of  the  displayed  questions  that  refine  the  problem  description.  Subsequently, 
the  refined  problem  description  is  matched  with  the  stored  cases  and  their  solutions  are 
displayed  in  descending  order  of  similarity  to  the  user,  who  can  (3)  decide  whether  to  (4)  select 
and  view  a  case  for  decision  making. 

Step  5:  Feature  organization : 

In  FACIT,  feature  organization  concerns  the  extraction  of  TCRS  taxonomies  from  a  set  of  given 
features.  We  introduced  and  evaluated  a  feature  organization  approach  named  TAXIND  in  (Gupta 
et  al.  2004).  However,  TAXIND  makes  the  simplifying  assumption  that  features  are  provided  as 
<question,  answer>  pairs  rather  than  in  logical  form.  Although  this  permitted  us  to  quickly 
develop  TAXIND  and  analyze  issues  in  feature  organization,  this  assumption  also  complicates 
the  process  of  identifying  subsumption  relations  among  features.  Thus,  while  TAXIND 
outperformed  a  baseline  algorithm,  its  performance  leaves  much  to  be  desired. 

We  instead  plan  to  organize  features  into  subsumption  taxonomies  using  the  following 
procedure.  First,  it  will  identify  feature  subsumption  relations  via  a  pair-wise  comparison  of  each 
feature.  Logical  form  expressions  can  be  complex.  Therefore,  initially  we  will  consider  only 
conjunctive  expressions.  The  lexicon  will  provide  the  domain  specific  knowledge  to  identify 
these  relations,  assessing  subsumption  using  three  types  of  relations  ( is-a-type-of  constituent, 
and  is-a-subevent ).  Additional  domain  knowledge,  in  the  form  of  implication  rules,  will  be  used 
as  needed.  For  example,  the  implication  rule 

NOT(EYENT)  =>  PROBLEM(EYENT) 

implies  that,  if  an  event  does  not  occur,  then  there  is  a  problem  with  the  event.  Thus,  we  can 
conclude  that  the  statement  “printing  Problem”  subsumes  the  statement  “Data  from  computer  is 
not  printed”.  To  assess  this  subsumption  relation,  our  procedure  will  generalize  the  logical  form 
of  the  statement  “Data  from  computer  is  not  printed”  by  reducing  the  conjuncts  to 
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NOT(PRINTED(HUMAN,DATA,PRINTING_INST))  and  then  applying  the  rule  shown  above 
to  obtain  the  further  generalization  PROBLEM(PRINTEVENT),  which  is  a  logical  form  for  the 
statement  “Printing  problem”. 

After  all  potential  subsumption  relations  are  identified,  directed  graphs,  each  representing  a 
taxonomy,  will  be  automatically  constructed  and  presented  to  the  domain  expert  for  verification. 

Step  6:  Case  index  assignment 

Indexing  a  taxonomic  case  involves  assigning  features  that  are  leaves  from  distinct  taxonomies. 
Using  the  logical  form  of  features  and  the  feature  taxonomies  as  a  reference,  FACIT  will  select 
only  the  most  specific  distinct  features  applicable  to  a  case  to  encode  it.  If  a  most  specific 
feature  in  the  case  is  not  a  leaf  from  one  of  the  taxonomies,  then  the  case  shall  be  brought  to  a 
domain  expert’s  attention  for  review  and  refinement. 

3r2.  Implementation  status 

A  complete  implementation  of  FACIT  requires  a  significant  development  effort.  Table  2 
summarizes  FACIT ’s  implementation  status,  identifying  both  planned  and  implemented 
components.  We  describe  these  with  respect  to  the  FACIT  step  that  they  address. 

We  have  developed  software  tools  that  support  the  development  and  maintenance  of  GSOs, 
including  the  Concept  Discovery  Workbench,  which  supports  the  semi-automatic  acquisition  of 
concepts  from  text  documents,  and  the  GSO  Editor,  which  allows  users  to  edit  new  and  existing 
concepts.  These  greatly  simplify  and  accelerate  the  development  and  maintenance  of  generative 
sublanguage  ontologies.  Also,  we  have  developed  and  evaluated  the  Acronym  Extractor  (AcE), 
an  automated  tool  for  identifying  and  extracting  acronyms  and  their  expansions  (Gupta  and  Aha 
2004a).  AcE  is  a  domain  independent  extraction  system  that  can  be  customized  to  a  specific 
domain  by  adding  a  suitable  domain  dictionary.  Our  empirical  comparisons  showed  that  AcE 
performs  as  well  as  or  better  than  two  other  systems.  However,  we  have  not  yet  implemented  the 
GSO  Learning  Workbench,  which  will  assist  us  with  updating  the  GSO  automatically. 

We  have  implemented  an  interface  to  the  Link  Parser  (Link  2004)  to  perform  syntactic  parsing. 
It  degrades  gracefully  when  presented  with  ill-formed  text  by  allowing  broken  links  or  structures. 
We  then  integrated  this  with  Brill’s  (1992)  part-of-speech  tagger  to  help  efficiently  select  better 
parses.  We  have  also  integrated  these  tools  with  AcE  and  RuMoP  (Gupta  and  Aha  2004b),  a 
morphotactic  parser  that  reduces  inflected  and  derived  terms  to  their  baseforms  for  subsequent 
lookup  in  our  semantic  lexicon. 

We  are  currently  implementing  a  preliminary  version  of  a  semantic  interpreter  (SemLink)  that 
will  operate  with  our  GSO  representation  and  the  output  of  the  syntactic  parser.  However,  this  is 
limited,  and  our  future  work  includes  developing  a  morpho-semantic  interpreter  to  derive  the 
meanings  of  morphological  inflections  and  derivations. 
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Table  2:  Planned  and  implemented  FACIT  components. 


FACIT  Step 

Component 

Complete? 

1.  Lexicon  Engineering 

Concept  Discovery  Workbench 

P 

Acronym  Extractor 

P 

GSO  Editor 

P 

GSO  Learning  Workbench 

2.  Syntactic  Parsing 

JLINK  Syntactic  Parser 

P 

JBrill  Part-of-speech  Tagger 

P 

Acronym  Extractor 

P 

RuMoP  Morphotactic  Parser 

P 

3.  Semantic  Interpretation 

SemLink 

P 

Morpho-semantic  Interpreter 

4.  Feature  Extraction 

Feature  Extractor 

5.  Feature  Organization 

TAXIND  (vl) 

P 

TAXIND  (v2) 

6.  Case  Index  Assignment 

Index  Assigner 

7.  Taxonomic  Conversational  Case  Retrieval 

Taxonomic  Case  Retrieval  System  (TCRS) 

P 

We  have  not  yet  implemented  a  feature  extraction  algorithm;  it  will  interact  with  the  user  to 
identify  features  of  interest.  No  case  index  assignment  module  currently  exists,  either,  although 
its  implementation  is  expected  to  be  straightforward.  As  mentioned  in  Section  3,  an  initial 
version  of  a  feature  organizer,  TAXIND,  exists.  However,  it  was  intended  only  as  a  placeholder, 
and  we  plan  to  develop  a  variant  that  inputs  features  in  logical  form. 

Finally,  TCRS  is  a  relatively  mature  tool.  We  have  demonstrated  that  it  performs  better  than  the 
standard  CCBR  approach  on  several  performance  measures  (Gupta  et  al.  2002). 

4t3.  Related  Work 

At  this  time,  we  are  not  aware  of  any  other  practical  implementations  of  generative  lexicon 
theory. 

FACIT  performs  knowledge  extraction  (KE)  (Cowie  and  Lehnert  1996),  which  differs  from 
information  extraction  (IE)  in  at  least  four  respects.  First,  KE  focuses  on  the  extraction  of 
categories  (e.g.,  rules,  models)  rather  than  instances  (e.g.,  addresses,  menus).  Second,  KE  must 
use  deep  natural  language  interpretation  process  to  accurately  identify  the  subtleties  in  meaning 
required  for  acceptable  extraction  performance.  In  contrast,  IE  approaches  effectively  employ 
shallow  parsing  techniques  along  with  extraction  patterns  where  subtleties  of  meaning  do  not 
have  a  significant  impact  on  extraction  performance.  Third,  KE  relies  on  only  a  few  extraction 
patterns  with  semantic  classes  and  logical  forms  as  triggers,  whereas  traditional  IE  employs  a 
large  library  of  domain  specific  patterns  with  terms  and  phrases  as  triggers.  Finally,  KE 
approaches  use  a  rich  ontological  representation  for  text  interpretation,  a  step  that  is  typically 
bypassed  in  traditional  IE  systems.  Instead  traditional  IE  systems  directly  apply  patterns  to 
shallow  parsed  text  for  extraction.  However,  traditional  IE  performance  is  sensitive  to  authoring 
styles  and  the  coverage  of  shallow  extraction  patterns,  thereby  creating  a  pattern  maintenance 
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problem.  FACIT  reduces  this  problem  by  relying  on  semantic  interpretation  and  less  on 
extraction  patterns.  It  effectively  reduces  feature  engineering  effort,  and  will  likely  yield  systems 
that  have  higher  recall  and  precision  performance  than  shallow  NLP  approaches  in  situations 
where  the  characterizing  features  are  not  known  a  priori. 

In  (Gupta  et  al.  2004),  we  compared  and  contrasted  FACIT  with  other  approaches  for  acquiring 
case  indices  from  text  documents.  Few  if  any  related  approaches  exist.  For  example,  SMILE 
(Bruninghaus  and  Ashley  1999),  an  approach  for  case  indexing,  only  performs  index  assignment 
based  on  a  predefined  feature  set.  In  contrast,  FACIT  also  performs  feature  extraction.  Hence,  it 
is  more  suited  to  dynamic  domains.  Furthermore,  FACIT’s  indexing  strategy  differs  greatly  from 
other  approaches  that  acquire  indices  for  cases  used  in  a  case-based  reasoning  methodology. 

§t4.  Future  Work 

Section  3  outlined  several  of  our  future  implementation  tasks,  which  must  be  completed  prior  to 
evaluating  FACIT  empirically.  Although  we  have  evaluated  several  of  its  components  (e.g., 
AcE,  RuMoP,  TAXIND,  TCRS),  a  complete  evaluation  will  differ  substantially  in  that  it  will 
require  interaction  with  subject  matter  experts  (for  Steps  4-6)  and  users  (Step  7).  We  plan  to 
assess  its  utility  on  a  range  of  both  user  and  system  performance  measures.  In  addition,  while  our 
first  performance  task  concerns  lesson  document  retrieval,  we  also  plan  to  assess  FACIT’s 
knowledge  extraction  performance  for  other  decision  support  tasks  (e.g.,  plan  extraction  from 
text  documents). 

FACIT  is  a  knowledge  intensive  framework;  it  benefits  from  extending  an  initial  linguistic 
ontology,  and  uses  rule  sets  for  both  semantic  interpretation  and  feature  organization.  Additional 
uses  of  domain  specific  knowledge  may  also  emerge  when  we  apply  FACIT  to  other  tasks.  Thus, 
we  will  investigate  approaches  for  decreasing  knowledge  acquisition  costs  for  the  lexicon,  rule 
sets,  and  other  information  sources. 

6r5.  Conclusion 

Interoperable  systems  require  representations  that  are  suitable  for  sharing  information  among 
their  agents,  and  decision  support  tools  are  no  exception.  These  tools  are  frequently  provided 
with  domain  specific  information  as  a  result  of  a  tedious  manual  knowledge  engineering  process, 
often  involving  the  encoding  of  information  obtained  from  text  sources.  We  described  the 
FACIT  knowledge  extraction  framework  and  its  promise  for  reducing  such  knowledge 
engineering  efforts.  FACIT  employs  generative  sublanguage  ontologies  to  support  the  semantic 
interpretation  of  text  documents  and  subsequent  feature  organization  tasks.  This  representation 
for  linguistic  knowledge  has  several  benefits  versus  existing  approaches,  and  can  be  a 
cornerstone  of  interoperable  agent-based  systems. 

However,  to  our  knowledge,  there  are  no  implementations  of  generative  linguistic  ontologies, 
other  than  our  own.  Furthermore,  FACIT’s  performance  task  is  challenging,  and  requires 
extensive  development  effort.  We  have  implemented  several  of  its  modules,  but  several  more 
require  implementation.  This  effort  seems  particularly  worthwhile,  and  should  yield  a  robust  and 
domain  independent  approach  for  interpreting  text  documents.  FACIT  yields  a  computable, 
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conceptual  representation  of  its  source  documents.  Thus,  after  its  implementation  is  complete, 
we  anticipate  applying  it  to  many  domains  and  tasks  of  interest. 
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•  CODE  Plug-In  Overview  (DOD/IHMC) 
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Ontologies  Enable  Interoperability 

Ontological  Design  Principles 

An  ontology  is 

•  Set  of  concepts  used  in  a  particular  domain  of  discourse 

•  Interrelationships  between  the  concepts 

-  behavioral  characteristics 

Ontological  engineers  try  to  optimize  the 
ontological  design 

-  operational  characteristics 

-  Parsimonious  design  of  concept  classes 

•  Ontologies  provide  a  framework  for  expressing  a  common 
lingua  to  be  utilized  across  systems 

•  Expressing  semantics  of  concepts  formally  through 
ontologies  enables  automated  reasoning,  desired 
functionalities  and  collaboration  across  systems 

-  Crispness  in  the  distinctions  across  concepts 

-  Richness  in  the  associations  across  concepts 

Pragati,  Inc.  Proprietary 
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Ontological  Concerns 

Information  overload  is  occurring  in  the  creation  of  ontologies 
Every  organization  “thinks”  their  “core  ontology”  will  be  the  Holy 
Grail  for  ontologies 

Reality  #1 :  The  notion  of  a  canonical  ontology  is,  at  least  at  present, 
a  myth 

Reality  #2:  We  currently  have  to  live  with  a  cloud  of  candidate 
ontologies  which  model  a  “real”  concept  from  different  perspectives 


Ontology  Developer’s  Dilemma: 

How  can  I  effectively  find  and  reuse 
concepts  from  that  "cloud"? 
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Vision 

Build  semantic  mediation  tools  to  aid 
-Identification  of  similar  patterns  across 
ontologies  and  information  systems 
-Construction  of  ontologies  through  information 
extraction  from  such  systems 
-Searching  for  concepts  in  ontologies  and  KBS 

-  Evaluate  potential  for  reuse 

-  Mapping  &  alignment  of  concepts  across 
ontologies 

-Reuse  of  concepts  through  adaptation  &  merging 
-Maintenance  of  Ontologies  and  KBS 

•  Comprehension 

•  Verification  &Validation 


MultiViewpoint  Clustering  Analysis 
(MVP-CA) 
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Multi-ViewPoint  Clustering  Analysis 


Approach: 

Cluster  a  knowledge  base  from  multiple  perspectives 


Clustering  of  knowledge  bases  into  groups  of 
semantically-related  rules/axioms  reveals 

-  Relationship  of  terms  in  the  context  of  their  usage 

-  Prototypical  patterns  of  usage  for  the  terms  in  the 
axioms 

Multiple  ways  of  clustering  (based  on  different 
objective  criteria)  aid  in  understanding  and  analyzing 
KBs  from  different  perspectives 


MVP-CA  Architecture 

KB/Ontology 
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IOD  Problem  Statement 

Data  and  knowledge  repositories  contain 

-  Large  amounts  of  unstructured  but 

-  Stylized  natural  language  text 

Simple  text-based  search  techniques  successful  in  retrieving 
somewhat  relevant  documents  to  a  human  analyst's  needs, 
Information  contained  in  those  documents  is  opaque  with  respect  to 

-  query 

-  manipulation 

-  reasoning  tools 

-  semantic  content  of  the  text 

Proposed  Solution 

Extract  semantic  content  from  the  text 
and 

capture  it  in  an  ontology 


Approach 

Analyze  the  data  set  to  generate  sub-sets  with 
related  concepts/similar  concepts  |  mvp-ca  1 

Generate  a  regular  expression  to  capture  the 
similarity  pattern  lip  top  Ml 

Map  the  regular  expression  to  an  ontology  fragment 
consisting  of  concepts  from  existing  ontologies  along 
with  new  concepts  [  IOD  and  Protege  ] 

Use  the  extraction  binding  (regular  expression  and 
the  mappings)  to  extract  new  instances  from  the  data 

Set  |  IOD  and  Protege  ) 
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Enable  the  Protege/OWL  Query 
Model 

Use  a  candidate  OWL  reasoning  system  such 
as  JTP  or  RACER: 

Query:  “What  is  the  mean  duration  of  reported 
turbulence  events?” 

Answer:  “a  mean  lower  bound  of  4  seconds, 
and  a  mean  upper  bound  of  7.5  seconds.” 

Collaborative  Ontology 
Development  Environment 
(CODE)-Plug-ln 

Pragati,  Inc.  Proprietary 
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CODE  Environment 

(Institute  for  Human  &  Machine  Cognition  (IHMC)) 

A  Collaborative  Environment  for 
Viewing,  Searching  and  Developing  Ontologies 

•  Ontology  Viewer - 

•  Transforms  DAML  ontologies  (written  in  RDF,  OWL,  etc.)  into  “natural” 

CMAPs 

•  Suppresses  mundane/obvious  information 

•  Determines  graph  layout  to  show  CMAPs 

•  Ontology  Search  -  Cruiser 

•  Searches  ontologies  locally  &  on  web 

•  Mechanisms  to  book  mark  ontologies 

•  Support  for  searching  for  concepts  in  these  ontologies 

•  Ontology  Development 

•  Drag  &  drop  support  for  incorporating  concepts  in  existing  ontologies 

•  CMAP  tools  for  graphical  editing  of  concepts 

•  Transformation  tools  from  CMAP  to  XML/RDF/DAML/OWL  format 

•  Real-time  collaboration  aids  for  geographically  distributed  groups 
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Issues  in  the  Cruiser 

MVP-CA  based  Plug-In  for  CODE 

•  No  semantic  underpinnings  for  searching  of  concepts 

•  No  cross  ontology  awareness 

•  Given  a  concept  extract  similar  concepts  from  across  a  wide  range  of 
Semantic  Web  (OWL)  ontologies  using  a  variety  of  matching  criteria 

-  Zoom-in  feature  unable  to  place  the  concept  in  the  broader  context 

•  Rank  the  matching  concepts  based  on  a  variety  of  relevance 

•  Information  overload  when  searching  for  relevant 

measures 

concepts 

•  Present  the  relevant  matching  concepts  in  the  context  of  the  source 

•  No  indication  of  relevance  ranking  in  the  retrieved 

ontology  along  with  the  vicinity  concepts 

ontologies 

•  Also,  utilize  MVP-CA  clusters  as  a  starting  point  for  rendering  of 

-  For  example,  culture  ( sociological  aspect  vs.  biological  experiment) 

CMAPs  so  as  to  simplify  their  presentation 

•  Denseness  of  CMAP  representation  despite  suppression 
of  mundane  information  in  the  RDF  concept  descriptions 

Pragati,  Inc.  Proprietary 
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Time  Clusters  across  SUMO  &  DAML 
Ontologies 

http://retiant  teknowledge  com/DAML-Time/SUMO.owl#TimePosition 

http://reliant.  teknowledge.  com/D AML-Time/SUMO.  owl#TimeMeasure 
http://reliant.  teknowledge.  com/DAML-Time/SUMO.owl#TimeDuration 
http://reliant.  teknowledge.  com/DAML-Time/SUMO.owl#Timelnterval 
http://reliant.  teknowledge.  com/D AML- Time/SUMO.  owl#TimePoint 

http://www.isi.edU/~pan/damltime/time.owl#TemporalEntityCollection 

http://www.isi.edU/~pan/damltime/time.owl#MetaTemporalEntityClass 

http://www.  isi.  edu/~pan/damltime/time.owl#lnstant 

http://www.  isi.  edu/~pan/damltime/time.  owl#lnterval 

http://www.  isi.  edu/~pan/damltime/time.  owl#MetaTemporalThingClass 

http://www.w3.Org/2002/07/owl#Class 

http://www.isi.edU/~pan/damltime/time.owl#TSeq 

http://www.isi.edU/~pan/damltime/time.owl#TemporalThing 

http://www.isi.edU/~pan/damltime/time.owl#TimeSpanClass 


OSRT  Vision 

A  tool  that  enables  builders  of  knowledge-based  systems 
to  identify  and  reuse  relevant  portions  of  existing 

Ontology  Search  &  Reuse  Tool 

systems,  thereby 

•  Reducing  development  time 

(OSRT) 

•  Amortizing  development  costs 

•  Enhancing  quality  of  developed  system 

overall  increase  in  return  on  investment  (ROI) 

Pragati,  Inc.  Proprietary 
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Ontology  Search  and  Reuse  Tool 


[  GCCS/JWARS  |  [  IMMACCS  ]  |  Cyc-IKB  ]  |  S1LS  [| 

(  OpenCyc  )  (  IOM  )  (  C2IEDM  ) 


* 
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Ontology  Developer’s  Dilemma 

•  Where  is  the  concept? 

-  Searching  for  the  relevant  concept 

•  How  is  it  used? 

-  Concept  perspectives  based  on  context  of  usage 

•  How  to  adapt  it? 

-  Concept  transformation  and  merging 


Queries 

•  Semantically  Rich  Queries 

-  Concept  Name 

-  Attribute  Name 

-  Generalization  Structure 

-  Association  Relationship 

-  Vicinity  Concept 

•  Repertoire  of  String  Matching  Algorithms 

-  Component  Vector  Overlap 

-  Substring  Matching 

•  Query  Plug-In  support 

-  To  allow  new  types  of  queries  to  be  easily  integrated  into  the  framework 

# 

Pragati,  Inc.  Proprietary 

Concept  Usage  Views 

Cognitive  Aids  for  Concept  Selection 

-  Definitions  View 

•  Displays  the  focus  concept  as  declared  in  the  ontological  hierarchy 
through  Embarcadero  Describe’s  XMI  export 

-  Vicinity  Concepts  View 

•  Displays  the  vicinity  concepts  -  concepts  that  co-occur  with  the  focus 
concept 

-  Rules  Usage  View 

•  Displays  the  cluster  of  rules  where  the  focus  concept  has  localized 

-  Templates  View 

•  Displays  the  templates  associated  with  the  cluster  of  rules 
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Ontological  Issues 

Conceptual/Modeling  Differences 

-  Level  of  Abstraction 

•  Concepts  are  too  specialized 

Example :  Ford  Taurus,  Toyota  Camry,  Honda  Accord 
=>  Automobiles 

•  Concept  is  too  general: 

Example :  Move  => 

Move-lnto,  Move-To,  Move-Out-Of,  Move-Through 

-  Placement  in  the  ontological  hierarchy 

Different  choices  on  specifying  ontological  distinctions  for  orthogonal  characteristics 
Example:  An  ontology  for  organizing  clothes  line  is  different  for 

(a)  department  store  layout  for  customers 

Gender  (mens’,  womens’) 

(b)  ordering  clothes  from  a  manufacturer 

Clothes-type  (pants,  shirts) 


Pragati,  Inc.  Proprietary 


* 


266 


Vicinity  Concepts  View 


Ontological  Issues 

Term  Relationships 

-  Vicinity  Terms  -  Terms  related  via  common  usage  patterns 

Example:  Pour,  Immerse,  Permeate 

-  Complementary/Inverse  terms 

Example:  Move-From  &  Move-To,  Exit  and  Enter 

-  Homonym  Terms  -  Context  determines  the  semantics 

Example :  Contract  ->  physical  change  vs.  legal  document 

Culture  ->  societal  issues  vs.  biological  experiment 

-  Overloaded  Terms  -  Same  semantics  for  very  different  contexts 

Example:  ObjectFoundlnLocation 


Ontological  Issues 

Term-conceptualization  and  Term-explication  Differences 

-  Lexically  and  semantically  close  terms 

Example:  Move  &  Move-lnto, 

Touches  &  TouchesDirectly 
Prevent  &  Prevents 

-  Lexically  distant  but  semantically  close  terms 

Example:  providesCoverlnCOA  &  providesConcealmentlnCOA 
TaskTypeRequiresAgentType,opTypeRequiresAgentType 

-  Lexically  reversed  but  semantically  close  terms 

Example:  ForwardPassageOfLines-MilitaryOperation  & 
PassageOfLines-Forward-MilitaryTask 
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Mapping  Aids 

Support  for  mapping  of  terms  across  ontologies  can  be 
provided  by  flagging  terms  that  are  used  in  similar 
contexts  or  similar  behavior  pattern 

Such  similarities  can  be  extracted  using  the  same 
technology  as  used  for  template  formulation  when 
applied  across  different  ontologies 


Pragati,  Inc.  Proprietary 
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Adaptation  Support 

•  Concept  Adaptation 

-  Copy  and  paste  into  target  ontology 

-  Edit  concept  attributes  and  relationships 

-  Merge  with  concepts  in  the  target  ontology 

•  Rules  Adaptation 

-  Display  MVP-CA  generated  templates  in  OSRT 


* 
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Envisioned  Extensions  to  OSRT 


Extend  OSRT’s  reuse  model  to  automatically  generate  mappings 
based  on  the  user’s  reuse  directives. 

Design  a  framework  to  map  instances  between  distinct,  but 
semantically  overlapping,  ontologies. 

Implement  import/export  plugins  appropriate  to  the  specific  ontology, 
instance,  and  mapping  representations  used  by  the  host  system. 
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Pragati  Tool  Suite 
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Uniqueness  of  Overall  Approach 

•  Allows  subtle,  semantically-oriented  analysis  of  ontologies 

•  Pattern-based  approach  for  clustering 

-  discovers  pattern-conforming/non-conforming  regions  in  KB 

•  Clustering  in  similarity  space  (instead  of  feature  space) 

-  Reveals  higher-level  information  on  relationships  across  concepts 

•  Clustering  axioms  is  based  on  usage  of  axioms  (independent  of 
the  declared  ontology) 

-  Reveals  information  of  tacit  nature  not  captured  in  the  ontology 

•  Domain  and  representation-independent 

-  Allows  flexibility  in  deploying  technology  to  any  semi-structured 
information  system 
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Benefits 


•  Cost-Effective  Solution  for  Building  and  Organizing 
Ontologies  &  KBs 

-  Less  time  needed 

-  Less  personnel  needed 

-  Effective  reuse  of  legacy  systems 

•  Quality  Solution  enabling  high-end  analysis  for 

-  Development 

-  Maintenance 

-  Interoperability 

•  Adaptive  Solution  to  Changing  Demands 

-  In  time  as  ontologies  evolve  across  applications 

-  In  perspective  for  different  types  of  users 
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INTRODUCTION 

Many  fundamental  assumptions  in  information  management  are  driven  by  the  nature  of  problems 
in  the  business  world,  and  by  the  kinds  of  technology  that  have  been  available.  The  distinctive 
nature  of  combat,  and  new  technical  developments,  invalidate  some  of  these  assumptions.  This 
paper  discusses  three  of  these  assumptions: 

•  That  users  need  access  to  everything; 

•  That  the  Global  Information  Grid  (GIG)  needs  a  global  semantic  standard; 

•  That  information  is  passive  (and  only  people  are  active). 

It  explains  why  each  assumption  is  invalid,  and  outlines  emerging  technologies  that  suggest  new 
directions  for  addressing  the  needs  that  these  assumptions  identify. 

ASSUMPTION  1:  UNIVERSAL  ACCESS 

The  vision  behind  the  “common  operational  picture”  (COP)  is  that  information  technology  will 
enable  every  user  to  have  access  to  any  piece  of  desired  information,  and  that  this  information 
will  be  consistent  across  all  users. 

There  is  no  question  that  many  users  want  access  to  all  information,  at  least  in  principle. 
However,  actually  delivering  such  access  may  be  technically  intractable  and  psychologically 
undesirable,  and  new  research  is  pointing  the  way  toward  mechanisms  that  will  enable 
information  systems  to  select  the  best  information  to  send  to  each  user. 

Why  is  Universal  Access  Inachievable? 

The  vision  of  making  all  information  available  to  all  users  faces  two  fundamental  limits,  one 
psychological  and  the  other  technical. 

Psychologically,  there  is  a  limit  to  the  amount  of  information  that  a  human  being  can  process. 
This  limit  is  illustrated  every  time  someone  searches  the  World  Wide  Web  using  a  search  engine 
such  as  Google.  These  searches  routinely  return  tens  of  thousands  of  results,  but  most  users 
consult  only  the  first  few  links  on  the  first  page. 

This  anecdotal  experience  is  borne  out  by  two  lines  of  research.  The  cognitive  limitations  of  the 
human  organism  were  highlighted  nearly  fifty  years  ago  in  George  Miller’s  classic  study,  “The 
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Magic  Number  Seven,  Plus  or  Minus  Two” 

[3].  Reviewing  a  broad  range  of 
psychological  studies,  he  found  a  sharp 
decrease  in  performance  when  people  were 
asked  to  manipulate  more  than  about  seven 
items  of  information  concurrently,  reflecting 
the  intrinsic  limits  of  human  attention.  More 
recently,  studies  in  artificial  life  [5]  show  that 
as  an  agent’s  knowledge  of  its  environment 
grows,  its  performance  first  increases,  then 
decreases  as  its  sensors  become  overloaded. 

Both  results  suggest  that  an  important 
function  of  an  information  system  is  striking 
a  balance  between  the  amount  of  information 
available  and  the  capacity  of  the  human  to  process  it. 

There  is  also  a  technical  limitation  to  global  information  access.  It  is  sometimes  assumed  that 
steady  technical  progress  in  telecommunications  will  eliminate  any  constraint  on  bandwidth,  and 
in  the  abstract,  great  gains  are  being  made  in  our  ability  to  move  information  around.  Practically, 
though,  it  is  unlikely  that  this  technology  will  be  available  to  operators  in  the  field  in  a 
reasonable  time  frame.  Figure  1  summarizes  a  recent  study  by  the  Office  of  Net  Assessment  [1] 
on  the  availability  of  commercial  and  planned  military  satellite  communications  resources  that 
could  be  used  in  case  of  military  emergency,  compared  with  projected  needs.  Commercial 
providers  have  moved  away  from  satellites  and  toward  fiber  for  their  backbones.  While  satellites 
could  support  military  communications  in  areas  far  removed  from  those  they  were  originally 
intended  to  support,  new  fiber  is  tied  to  specific  regions,  and  is  not  available  to  support  conflicts 
in  (say),  the  empty  quarter  of  Iraq. 

Thus,  fundamental  limitations  in  both  human  and  technical  capacity  make  it  unwise  to  plan  an 
information  system  around  the  assumption  that  every  user  can  in  principle  have  access  to  all 
information. 

What  is  the  Alternative  to  Universal  Access? 

If  we  cannot  provide  all  information  to 
every  user,  we  must  be  selective,  filtering 
the  available  information  to  match  the 
user’s  needs.  Two  basic  approaches  are 
available:  deterministic  and  stochastic 
filtering  (Figure  2). 

Deterministic  filtering  uses  a  formal  logical 
analysis  (often  based  on  symbolic  artificial 
intelligence)  to  match  the  user’s  interests 
against  available  information  and  select  the 
information  that  is  most  likely  to  be 
relevant.  This  approach  is  attractive 
because  the  user  can  understand  the  logical 
rules  used  to  select  the  relevant 
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information,  and  thus  gain 
confidence  that  the  system  will 
deliver  the  required  material. 

Unfortunately,  as  the  volume  of 
available  information  grows,  this 
confidence  can  be  disappointed, 
because  of  the  computational 
complexity  of  the  processing 
involved.  It  is  intuitive  that  as  the 
amount  of  information  that  needs  to 
be  reviewed  increases,  the  time 
necessary  to  review  it  will  increase 
as  well.  If  the  processing  time 
increases  as  a  polynomial  of  the  size 
of  the  input,  it  is  reasonable  to  rely  on  more  powerful  computers,  or  larger  number  of  computers, 
to  meet  the  challenges  of  expanding  information.  However,  deterministic  logical  methods, 
especially  those  that  confront  realistic  representations  of  semantic  structure,  tend  to  be  NP-hard. 
That  is,  the  length  of  time  required  to  execute  the  logic  increases  exponentially  in  the  length  of 
the  input,  and  problems  that  are  larger  than  toy  examples  will  not  be  able  to  complete  in  a 
reasonable  length  of  time  even  on  the  fastest  computers  we  can  imagine. 

Deterministic  filtering  is  intractable,  but  stochastic  filtering  is  not.  In  its  simplest  form,  stochastic 
filtering  simply  means  that  we  select  randomly  from  the  available  information.  Purely  random 
selection  is  unlikely  to  provide  any  information  that  is  relevant  to  the  user’s  interests,  but  it  is 
possible  to  weight  the  selection  in  such  a  way  that  the  retrieved  information  is  more  likely  to  be 
relevant  to  the  user’s  interests.  We  have  been  developing  mechanisms  for  stochastic  filtering, 
inspired  by  the  mechanisms  that  insects  use  to  sort  their  nests  and  coordinate  their  actions  [6]. 
These  mechanisms,  known  collectively  as  “stigmergy,”  use  the  environment  in  which  insects  live 
as  a  locally  indexed  communication  mechanism  [4],  In  this  approach  (Figure  3),  digital  ants 
swarm  over  a  massive  colleciton  of  documents,  recognize  fragments  of  a  concept  map  that 
represents  the  user’s  interests,  and  self-organize  to  populate  the  map  with  documents  relevant  to 
its  underlying  assumptions.  Stigmergic  mechanisms  have  several  desirable  features. 

•  For  many  such  processes,  the  quality  of  the  solution  (for  example,  the  number  of 
relevant  documents  retrieved)  increases  exponentially  over  time.  That  is,  initially  the 
number  of  documents  grows  very  rapidly,  providing  an  initial  basis  for  the  user’s 
decisions.  If  the  user  has  longer  to  wait,  the  process  will  continue  to  yield  improved 
results,  although  at  a  slower  rate. 

•  The  process  can  easily  be  distributed  over  many  machines,  without  the  need  for  central 
coordination. 

•  The  process  continues  to  operate  even  in  the  face  of  dynamic  change  (for  instance,  shifts 
in  the  user’s  interests  or  in  the  body  of  information  available),  without  the  need  to  be 
restarted. 


273 


ASSUMPTION  2:  GLOBAL  SEMANTIC  STANDARD 

One  of  the  greatest  contributions  of  the  Internet  has  been  to  lower  the  walls  separating  different 
bodies  of  information.  Information  that  twenty  years  ago  required  a  trip  to  the  library  can  now  be 
accessed  by  a  few  keystrokes  from  one’s  desk.  Many  different  information  producers  have 
eagerly  made  their  resources  available,  in  a  move  toward  a  single  global  information  grid,  or 
GIG. 

Unfortunately,  we  have  learned  that  exchanging  the  form  of  information  is  much  simpler  than 
exchanging  its  meaning.  Any  body  of  information  rests  on  an  assumed  way  of  conceptualizing 
the  world,  called  an  “ontology.”  For  example,  people  who  talk  about  automobiles  agree  in 
advance  that  a  car  consists  of  a  body,  a  power  system,  wheels  and  suspension,  and  an  interior, 
and  that  options  for  power  systems  include  gasoline,  diesel,  natural  gas,  electric,  and  hybrid, 
while  veterinarians  concerned  with  horses  focus  on  legs  and  hooves,  hair  and  skin,  and  internal 
organs. 

Experience  has  shown  that  there  is  no  single  “right”  ontology  for  describing  the  world.  Different 
information  producers  tend  to  have  different  ontologies,  making  it  difficult  to  combine  their 
information  in  a  single  application.  A  traditional  way  to  deal  with  this  divergence  is  to  attempt  to 
outlaw  it,  by  developing  a  single  ontology  that  all  producers  agree  to  use.  This  approach  is 
impractical.  Fortunately,  new  technical  tools  are  making  it  possible  to  combine  information  from 
systems  with  globally  incompatible  ontologies. 

Why  is  a  Global  Semantic  Standard  Impractical? 

There  are  three  obstacles  to  the  vision  of  a  single  global  semantic  standard:  the  existence  of 
established  inconsistent  ontologies,  the  complexities  of  translation,  and  the  fact  of  continuous, 
rapid  change  in  local  contexts. 

First,  there  are  many  established  communities  of  practice,  each  with  its  established  view  of  the 
world  that  makes  its  own  activities  efficient  and  internally  coherent.  As  valuable  as  a  global 
standard  may  be  for  people  who  work  across  different  communities,  it  will  impose  severe  costs 
on  the  existing  ontologies  that  it  displaces,  costs  that  are  often  high  enough  to  dissuade  the  users 
of  existing  systems  from  abandoning  them. 

One  might  hope  that  an  automatic  mechanism  could  be  found  to  translate  automatically  among 
different  ontologies,  thus  permitting  people  to  use  their  existing  systems  while  keeping  them 
aligned  to  the  global  standard.  The  second  obstacle  to  a  global  semantic  standard  is  that  the 
problem  of  aligning  ontologies  belongs  to  the  class  of  NP-hard  problems  described  in  the 
previous  section  [2],  That  is,  for  ontologies  of  realistic  size,  a  program  to  align  them  with  one 
another  would  not  be  able  to  deliver  results  in  reasonable  time. 

The  third  obstacle  is  that  ontologies  are  not  static.  They  are  constantly  evolving  to  support  the 
needs  of  the  communities  that  use  them.  In  a  dynamic  environment  (such  as  the  US  military  in  a 
time  of  transformation),  there  will  be  strong  pressures  on  local  groups  to  specialize  or  refine  the 
portions  of  the  ontology  that  they  use  the  most.  If  a  global  ontology  outlaws  such  specializations, 
it  will  severely  limit  the  productivity  of  its  users;  if  it  does  not,  it  will  soon  become  irrelevant. 

The  fundamental  issue  is  that  thought  is  dynamic,  constantly  exploring  new  combinations  and 
relationships.  Any  attempt  to  codify  the  infrastructure  of  thought  runs  the  risk  of  limiting 
creativity  and  mental  productivity. 
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What  is  the  Alternative  to 
a  Global  Semantic 
Standard? 

It  is  a  fact  of  ontological  life  that  the 
overall  semantic  structures 
underlying  different  systems  will 
differ  from  one  another.  Instead  of 
trying  to  impose  a  global  standard, 
an  alternative  approach  recognizes 
that  most  processes  that  cross 
systems  require  agreement  only  in  a  local  region  of  the  ontology.  Figure  4  illustrates  this 
graphically.  Even  though  the  two  structures  diverge  from  one  another,  they  are  aligned  in  a  local 
region,  and  as  long  as  the  interactions  between  them  affect  only  this  region,  the  more  remote 
differences  have  little  impact. 

Altarum’s  Living  Ontologies  technology  supports  this  alternative  approach  by  enabling 
knowledge  workers  (for  example,  system  modelers)  to  integrate  different  ontologies  in  their 
activities.  The  technology  supports  several  processes  that  can  be  interleaved  with  one  another. 

•  Modelers  can  search  existing  ontologies  for  concepts  and  substructures  that  are 
candidates  for  concepts  that  they  need  to  represent. 

•  They  can  compare  these  candidates  with  one  another  and  with  new  constructs  to  assess 
the  degree  of  consistency  among  them,  thus  promoting  agreement  where  possible  without 
imposing  a  single  global  standard. 

•  They  can  then  construct  new  systems  by  combining  the  candidate  structures  they  have 
retrieved  and  evaluated,  all  the  while  monitoring  the  growing  model  for  its  consistency 
with  existing  structures. 

ASSUMPTION  3:  PASSIVE  INFORMATION 

Before  the  computer  era,  information  took  the  form  of  ink  on  paper.  It  was  completely  passive, 
and  depended  on  people  to  file  it,  retrieve  it,  transport  it,  interpret  it,  and  act  on  it. 

In  many  ways,  computer  systems  have  simply  automated  this  view  of  information.  The  database 
or  web  server  has  replaced  the  filing  cabinet  or  library,  and  email  has  taken  the  place  of  physical 
couriers,  but  people  still  must  make  the  decisions  and  take  the  actions  to  manipulate  knowledge. 
In  the  email  model  (Figure  5,  top),  the  current  holder  of  information  must  know  who  would  find 
it  useful  and  send  it  there.  In  the  web 
model  (Figure  5,  bottom),  someone  who 
needs  information  must  know  where  it  is, 
and  retrieve  it.  In  both  cases,  information 
is  passive,  and  all  decisions  about  it  must 
be  made  by  people. 
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Figure  5:  Passive  information  being  sent  (top)  or 
retrieved  (bottom) 
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Figure  4:  Divergent  structures  that  are  locally 
aligned. 
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Why  is  Passive  Information  Undesirable? 

Passive  information  was  the  only  option  in  the  days  of  ink  on  paper.  Today,  the  line  between 
data  and  process  is  extremely  fuzzy.  Both  consist  of  a  machine-readable  list  of  ones  and  zeroes, 
and  there  is  no  intrinsic  reason  why  one  (the  process)  should  be  active  while  the  other  (the 
information)  is  passive.  We  can  imagine  an  architecture  in  which  each  packet  of  information  is 
self-conscious  about  its  contents  and  is  actively  seeking  users  who  might  find  it  valuable  (Figure 
6).  There  are  two  reasons  to  pursue  such  a  vision  of  active  information. 

First,  as  we  have  already  noted,  the 
cognitive  burden  on  users  is 
increasing  as  the  amount  of 
information  available  continues  to 
grow.  Anything  we  can  do  to  reduce 
this  cognitive  burden  will  make 
information  systems  more  effective. 

Second,  the  passive  information  model  (Figure  5)  forces  a  rigid  and  often  unrealistic  distinction 
between  the  producers  of  information,  who  need  to  identify  possible  users  to  whom  they  can 
send  reports,  and  the  consumers  of  information,  who  need  to  locate  likely  sources  to  which  they 
can  send  queries.  This  distinction  is  often  inappropriate.  Most  people  who  are  seeking 
information,  do  so  in  order  to  support  their  own  information  production  tasks. 

What  is  the  Alternative  to  Passive  Information? 

Altarum  has  developed  an  alternative  to  passive  information  known  as  PARTNER  (Population  of 
Agents  for  Real-Time  Networking  with  Emergent  Routing).  A  PARTNER  system  has  three 
species  of  agents. 

1 .  Domain  agents  produce  and  consumer  information.  They  may  be  people,  on-line  sensors, 
legacy  databases,  or  similar  entities. 

2.  Message  agents  are  packets  of  information  that  circulate  in  the  network.  A  message  agent 
is  neither  a  query  nor  a  report,  but  a  packet  containing  some  known  details  and  a 
description  of  some  unknown  details  that  could  naturally  be  related  to  the  known  details. 
Its  mission  in  life  is  to  find  other  message  agents  that  complement  its  own  knowledge, 
and  bring  them  to  the  attention  of  domain  agents  whom  it  knows  and  who  might  be 
interested  in  information  related  to  its  own  contents. 

3.  Network  agents  are  the  computers  that  populate  the  network.  They  provide  three  services 
to  the  message  agents.  Like  routers  in  any  communications  system,  they  move  them 
around  and  store  them  when  they  are  not  moving.  In  addition,  they  provide  processing 
resources  that  message  agents  can  use  to  compare  themselves  with  one  another. 

PARTNER  agents  perceive,  react  to,  and  reinforce  two  fields  in  their  environment, 
simultaneously  coordinating  their  activities  and  controlling  the  use  of  resources  (Table  1).  A 
semantic  field  imitates  the  use  of  pheromones  in  insect  societies,  and  guides  mutually  relevant 
messages  toward  each  other  through  the  network.  An  economic  field,  modeled  on  naturally 
occurring  markets,  helps  messages  use  network  resources  responsibly  as  they  travel. 
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The  semantic  field  is  based  on  a  signature  that 
can  be  associated  with  any  agent,  and  used  to 
assess  its  similarity  with  other  agents.  The 
data  in  a  signature  can  be  either  explicit  (the 
role  and  ID  of  a  domain  agent;  metadata 
associated  with  a  message  agent;  the  location, 
capacity,  and  connectivity  of  a  network  agent) 
or  derived  (a  keyword  or  concept  vector,  the 
texture  of  an  image).  These  examples  can  all 
be  precomputed,  but  signatures  can  also 
contain  dynamic  information  developed  during  the  lifetime  of  a  message  agent,  such  as  profiles 
of  what  users  have  found  a  given  item  interesting. 

A  message’s  sender  initializes  its  behavior  in  these  two  fields,  assigning  its  contents  (thus 
initializing  its  signature  and  determining  its  semantic  behavior)  and  its  budget  (determining  its 
economic  behavior).  Network  agents  maintain  the  two  fields  based  on  the  messages  they  handle. 
Message  agents  move  through  the  network,  leaving  traces  of  their  signature  on  the  nodes  through 
which  they  pass,  and  following  such  traces  to  find  other  similar  messages.  When  two  message 
agents  with  similar  signatures  meet,  they  compare  themselves,  and  if  they  are  indeed  similar, 
they  notify  the  domain  agents  who  originated  them.  If  the  match  produces  useful  information,  the 
domain  agents  pay  the  message  agents  a  reward,  increasing  their  budgets.  At  the  same  time, 
every  action  that  a  message  agent  takes  (moving  from  one  network  agent  to  another,  occupying 
storage,  comparing  itself  with  other  message  agents)  decrements  its  budget.  Message  agents 
whose  budget  reaches  zero  are  removed  from  the  system,  thus  preventing  congestion. 

Such  an  information  ecosystem  has  several  useful  global  behaviors. 

•  The  lifetime  of  information  in  the  system  is  not  fixed  by  policy,  but  emerges 
dynamically,  based  on  the  initial  budget  and  the  subsequent  rewards  that  domain  agents 
pay  to  each  message  agent.  Information  that  proves  to  be  valuable  will  persist,  while 
information  that  is  not  used  will  be  removed  (or  archived  to  a  server  that  itself  can  serve 
as  a  domain  agent). 

•  The  semantic  field  will  lead  to  message  agents  naturally  congregating  at  certain  network 
agents  based  on  their  signatures.  Such  concentrations  will  strengthen  the  semantic  field 
around  those  network  agents,  enabling  other  message  agents  to  find  them  more  easily. 
Thus  the  system  naturally  self-organizes  to  provide  efficient  access  to  related 
information. 

•  The  flow  of  currency  through  the  system  is  a  natural  way  to  monitor  the  value 
contributed  by  different  components.  For  example,  network  agents  that  accumulate  more 
usage  fees  than  others  could  use  these  fees  to  supplement  their  physical  resources,  thus 
guiding  infrastructure  investments  based  on  actual  usage  patterns. 

•  Perhaps  most  important,  the  system  eases  the  cognitive  load  on  human  domain  agents. 
Information  producers  do  not  need  to  know  who  could  use  their  products,  nor  do 
consumers  need  to  know  whom  to  ask.  Users  simply  introduce  message  agents  into  the 
system,  and  the  system  will  tell  them  when  those  packets  of  information  have 
encountered  other  packets  that  might  be  useful  to  them.  Instead  of  a  synchronous  process 
of  query  and  response  driven  by  human  action,  the  system  learns  the  interests  of  its  users 
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and  proactively  helps  them  find  both  information  and  other  users  that  can  support  their 
activities. 

SUMMARY 

Current  information  management  systems  are  constrained  by  assumptions  developed  in  the  days 
of  stand-alone  computer  systems,  or  even  pre-computer  paper  and  ink  repositories.  These 
systems  cannot  accommodate  the  dynamic  requirements  of  today’s  military.  Fortunately,  new 
computing  technologies,  such  as  stochastic  filtering,  living  ontologies,  and  active  information, 
permit  us  to  challenge  the  old  assumptions  and  develop  new  systems  that  offer  a  revolutionary 
advance  in  effectiveness  and  efficiency.  The  Altarum  Institute  has  demonstrated  many  of  these 
technologies  in  its  research  programs,  and  is  actively  pursuing  their  deployment  in  real-world 
applications. 
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Operating  in  an  Event  Driven  Environment 

■  “On  the  first  of  February  2003,  space  shuttle  falls  out  of  the  sky.  Within  90 
minutes,  we  had  to  set  up  a  critical  information  exchange  environment  with  15 
organizations  that  we  had  not  even  so  much  as  made  a  phone  call  to.  What 

elements  of  planning  can  you  do  when  you  don't  even  know  who  your 
partners  are  on  an  event-driven  basis?” 

“You  have  to  figure  out  how  to  dynamically  create  trusted  information 
exchange  environments,  dynamically  manage  them,  and  have  them  go  away 
when  no  longer  required” 

“Tomorrow  at  lunch,  I'm  going  to  address  the  semi-annual  meeting  of  the 
National  Institute  for  Urban  Search  and  Rescue.  How  many  of  those  folks 
you  think  have  a  classification  or  clearance  of  some  kind?  I've  got  news  for 
you.  There  are  2.5  million  of  those  folks  who  potentially,  depending  on  the 

event,  I  have  to  exchange  information  with” 


Quotes  from  MG  Meyerrose  (NORTHCOM)  to  the  JWID  Final  Planning  Conference  (FPC)  in  Chesapeake, 
VA  on  Tuesday  30  March  2004 


Dynamic  Team  Management 
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I  IBM  Software  Groyp 


The  Dynamic  Team  Management  Solution 

The  Dynamic  Team  Management  (DTM)  Solution  is 
comprised  of  two  COTS  components 
Integrated  Directory  Services 

Collaborative  Tools 


DTM  was  assembled  by  IBM  in  cooperation  with  DISA  and 
MITRE  to  support  participating  organizations  in  the 
Homeland  Security/Homeland  Defense  Command  and 
Control  Advanced  Concept  Technology  Demonstration 
(HLS/D  C2  ACTD) 


DTM  Implementation  in  JWID  04’ 


Joint  Warrior  Interoperability  Demonstration  (JWID  04’) 

June  04’ 

Dynamic  Team  Management  addresses  HLD/Military  Assistance  to 
Civil  Authorities  (MACA)  mission  requirements  for  ad  hoc 
collaboration  with  organizations  outside  the  military  enterprise. 

DTM  Locations 

NORTHCOM  -  Colorado  Springs,  CO 
DISA  Eagle  -  Falls  Church,  VA 
NSWC  Dahlgren  -  Dahlgren,  VA 
Hanscom  AFB  -  Bedford,  MA 


Dynamic  Team  Management 


Locate 

In  preparation  for,  during,  or  in  response  to  an  event,  rapidly  assemble  a 
team,  across  agency  boundaries,  based  on  a  variety  of  factors 
(name,  department,  role,  geography,  skill  etc) 

Invite 

Using  information  provided  during  the  location  of  those  individuals  or  roles, 
invite  them  to  collaborate 
Authenticate 

Using  authentication  information  previously  available  or  now  provided, 
authenticate  those  individuals  or  roles 
Collaborate 

Working  together,  synchronously  or  asynchronously  to  solve  a  problem 
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Dynamic  Team  Management  Challenges 

Accommodating  differing  directory  formats,  schemas,  and  vocabulary 

Flexibly  address  directory  sharing  requirements/restrictions 

Maintaining  currency  of  directory  information 

Scaling  collaboration  as  the  situation  evolves 

Locating  the  proper  individuals/roles  (expertise,  responsibility)  when 

team  building 

Communicating/collaborating  with  organizations  that  you  have  never 
worked  with  before 

Avoiding  one  focal/choke  point  within  an  organization  (single  point  of 
failure) 

Communicating  via  roles  as  well  as  individuals 
Capturing  organizational  reporting  relationships 
Enable  applications  to  leverage  integrated  directory  information 
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HLS  Dynamic  Team  Management  Example 


Dvnamic  Team  Manaaement 


Dynamic  Team  Management  Components 


Integrated  Directory  Services  Component 

Integrate  Directories  across  agency,  company,  and  organizational  boundaries, 

utilizing  the  native  format  and  schema  of  the  data 

Provide  the  Directory  information  to  other  applications  via  LDAP  and  Web 

Services 

Collaborative  Tools  Component 

Locate  Individuals  or  Roles  based  on  a  variety  of  methods  (name, 
organization,  department,  e-mail  address  etc.) 

Constructing  custom  teams  of  individuals  to  support  particular  missions  or 
tasks,  based  on  emerging  needs 

Invite  those  team  members  to  collaborate  synchronously  or  asynchronously 
Team  Members  login  and  participate  to  solve  problems 
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Scenarios  supporting  “event  driven”  operations 

1  -  Pre  Integrated 

Organizations  that  have  agreed,  ahead  of  time,  to  integrate  their  directories 

2  -  Dynamic  Assembly  (business  rules  pre-determined) 

Organizations  that  have  agreed,  ahead  of  time,  that  their  directory  information  is  only 
to  be  used  in  conjunction  with  a  pre-defined  event. 

3  -  Dynamic  Assembly  (ad  hoc  determination  of  business  rules) 

Integrating  an  Organization’s  directory  without  any  prior  notice,  “on  the  fly” 

4  -  Manual  Entry 

Supporting  those  organizations  who,  for  a  variety  of  reasons  (security,  connectivity) 
cannot  or  will  not  share  components  of  their  directory,  and  must  be  supported  in 
another  manner 
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Summary 


Build  the  best  teams  to  address  each  mission/task 

Accommodate  information  sharing  policies  and  procedures  of  contributing 
organizations 

Automate  directory  discovery,  integration,  and  synchronization 

Scale  to  meet  dynamic  cross-organization  communication  and  collaboration 
requirements 

The  key  is  not  the  implementation  of  a  specific  solution,  it  is  about  how  it  is  built. 
Interoperability  &  Collaboration 
Leveraging  Existing  Applications 
Leverage  Commercial  Implementations 
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